Re: [committed] libstdc++: Format Python code according to PEP8

[Eric Gallager via Gcc-patches]

On Tue, Sep 12, 2023 at 7:46 AM Jonathan Wakely via Gcc-patches
 wrote:
>
> Tested x86_64-linux. Pushed to trunk.
>
> -- >8 --
>
> These files were filtered through autopep8 to reformat them more
> conventionally.
>

Thanks for this; I'm wondering if it might be worthwhile to do
likewise for other python scripts elsewhere in the repository? e.g. in
contrib/

> libstdc++-v3/ChangeLog:
>
> * python/libstdcxx/v6/printers.py: Reformat.
> * python/libstdcxx/v6/xmethods.py: Likewise.
> ---
>  libstdc++-v3/python/libstdcxx/v6/printers.py | 651 +++
>  libstdc++-v3/python/libstdcxx/v6/xmethods.py |  58 +-
>  2 files changed, 446 insertions(+), 263 deletions(-)
>
> diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py 
> b/libstdc++-v3/python/libstdcxx/v6/printers.py
> index 37a447b514b..c0056de2565 100644
> --- a/libstdc++-v3/python/libstdcxx/v6/printers.py
> +++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
> @@ -18,10 +18,12 @@
>  import gdb
>  import itertools
>  import re
> -import sys, os, errno
> +import sys
> +import os
> +import errno
>  import datetime
>
> -### Python 2 + Python 3 compatibility code
> +# Python 2 + Python 3 compatibility code
>
>  # Resources about compatibility:
>  #
> @@ -38,7 +40,7 @@ import datetime
>  # 
>
>  if sys.version_info[0] > 2:
> -### Python 3 stuff
> +# Python 3 stuff
>  Iterator = object
>  # Python 3 folds these into the normal functions.
>  imap = map
> @@ -47,7 +49,7 @@ if sys.version_info[0] > 2:
>  long = int
>  _utc_timezone = datetime.timezone.utc
>  else:
> -### Python 2 stuff
> +# Python 2 stuff
>  class Iterator:
>  """Compatibility mixin for iterators
>
> @@ -98,6 +100,8 @@ except ImportError:
>  # Starting with the type ORIG, search for the member type NAME.  This
>  # handles searching upward through superclasses.  This is needed to
>  # work around http://sourceware.org/bugzilla/show_bug.cgi?id=13615.
> +
> +
>  def find_type(orig, name):
>  typ = orig.strip_typedefs()
>  while True:
> @@ -116,8 +120,10 @@ def find_type(orig, name):
>  else:
>  raise ValueError("Cannot find type %s::%s" % (str(orig), name))
>
> +
>  _versioned_namespace = '__8::'
>
> +
>  def lookup_templ_spec(templ, *args):
>  """
>  Lookup template specialization templ
> @@ -139,6 +145,8 @@ def lookup_templ_spec(templ, *args):
>
>  # Use this to find container node types instead of find_type,
>  # see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91997 for details.
> +
> +
>  def lookup_node_type(nodename, containertype):
>  """
>  Lookup specialization of template NODENAME corresponding to 
> CONTAINERTYPE.
> @@ -168,6 +176,7 @@ def lookup_node_type(nodename, containertype):
>  pass
>  return None
>
> +
>  def is_member_of_namespace(typ, *namespaces):
>  """
>  Test whether a type is a member of one of the specified namespaces.
> @@ -181,6 +190,7 @@ def is_member_of_namespace(typ, *namespaces):
>  return True
>  return False
>
> +
>  def is_specialization_of(x, template_name):
>  """
>  Test whether a type is a specialization of the named class template.
> @@ -195,12 +205,14 @@ def is_specialization_of(x, template_name):
>  return re.match('^std::(%s)?%s<.*>$' % (_versioned_namespace, 
> template_name), x) is not None
>  return re.match('^std::%s<.*>$' % template_name, x) is not None
>
> +
>  def strip_versioned_namespace(typename):
>  global _versioned_namespace
>  if _versioned_namespace:
>  return typename.replace(_versioned_namespace, '')
>  return typename
>
> +
>  def strip_inline_namespaces(type_str):
>  "Remove known inline namespaces from the canonical name of a type."
>  type_str = strip_versioned_namespace(type_str)
> @@ -212,6 +224,7 @@ def strip_inline_namespaces(type_str):
>  type_str = type_str.replace(fs_ns+'v1::', fs_ns)
>  return type_str
>
> +
>  def get_template_arg_list(type_obj):
>  "Return a type's template arguments as a list"
>  n = 0
> @@ -223,6 +236,7 @@ def get_template_arg_list(type_obj):
>  return template_args
>  n += 1
>
> +
>  class SmartPtrIterator(Iterator):
>  "An iterator for smart pointer types with a single 'child' value"
>
> @@ -238,28 +252,29 @@ class SmartPtrIterator(Iterator):
>  self.val, val = None, self.val
>  return ('get()', val)
>
> +
>  class SharedPointerPrinter:
>  "Print a shared_ptr, weak_ptr, atomic, or atomic"
>
> -def __init__ (self, typename, val):
> +def __init__(self, typename, val):
>  self.typename = strip_versioned_namespace(typename)
>  self.val = val
>  self.pointer = val['_M_ptr']
>
> -def children (self):
> +def children(self):
>  return SmartPtrIterator(self.pointer)
>
>  # Return the _Sp_counted_base<>* that holds the refcounts.
> -   

Re: [PATH] [CLEANUP] Remove trailing whitespace characters

[Eric Gallager via Gcc-patches]

On Mon, Sep 11, 2023 at 9:43 AM Jakub Jelinek via Gcc-patches
 wrote:
>
> On Mon, Sep 11, 2023 at 09:27:48AM -0400, David Malcolm via Gcc-patches wrote:
> > On Sun, 2023-09-10 at 16:36 +0200, Guillaume Gomez wrote:
> > > When going through the code, I saw a lot of trailing whitespace
> > > characters so I decided to write a small script that would remove
> > > them. I didn't expect there would be so many though... Not sure if
> > > patch with so many changes are accepted like this or if I should send
> > > more focused one.
> >
> > I'm not sure either.
> >
> > Some notes on the patch:
>
> IMHO testsuite shouldn't be touched at all, there are certainly tests
> which test whether such sources are handled correctly.
>
> Non-C/C++ sources shouldn't be changed this way either.
>
> The ^L stuff should be preserved, not removed.
>
> And even with that, I'm not sure it is a good idea to change it because
> it will be a nightmare for git blame.
>

Some git hosting services have added support for special files to
ignore revisions like this in git blame, for example, on GitHub, it's
called .git-blame-ignore-revs:
https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/
See for example:
https://github.com/cooljeanius/highlight.js/blob/main/.git-blame-ignore-revs

> The usual way of fixing up formatting if it was committed in a broken way
> is only when one is touching with real code changes something, fixing up
> formatting on it or around it is fine.
>
> If we decide to fix formatting in bulk, I think we should have a flag day
> and change also other formatting mistakes at the same time (say 8 spaces
> instead of tabs for start of line indentation (before first non-blank
> character), = at the end of line except for static var initializers, etc.
> But to make that worthwhile, it would be better to then have a pre-commit
> hook that would enforce formatting.  And, we haven't managed to come up with
> something like that yet.
>
> Jakub
>

Re: [PATCH] libstdc++: Reduce output of 'make check'

[Eric Gallager via Gcc-patches]

On Fri, Sep 8, 2023 at 6:32 AM Jonathan Wakely  wrote:
>
> On Fri, 8 Sept 2023 at 03:16, Eric Gallager  wrote:
> >
> > Maybe use $(AM_V_at) instead? That would allow it to be controlled by
> > the --enable-silent-rules flag to configure, as well as make V=1 vs.
> > make V=0 too.
>
> I see two problems with that. Firstly, nobody uses that configure
> option, so the net result would be that these 39 lines are still
> printed for everybody.
>
> Secondly, why would anybody ever want this output? Having it
> configurable (and default to noisy) just doesn't seem helpful.
>
> This is the output I'm talking about:
>
> make: Entering directory
> '/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/testsuite'
> make  check-DEJAGNU
> make[1]: Entering directory
> '/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/testsuite'
> Making a new site.exp file...
> AR="ar --plugin /home/jwakely/src/gcc/build/./gcc/liblto_plugin.so";
> export AR; \
> RANLIB="ranlib --plugin
> /home/jwakely/src/gcc/build/./gcc/liblto_plugin.so"; export RANLIB; \
> if [ -z "" ] && [ -n "" ]; then \
>  rm -rf normal-parallel || true; \
>  mkdir normal-parallel; \
>  make  check-DEJAGNUnormal1 check-DEJAGNUnormal2 check-DEJAGNUnormal3
> check-DEJAGNUnormal4 check-DEJAGNUnormal5 check-DEJAGNUnormal6
> check-DEJAGNUnormal7 c
> heck-DEJAGNUnormal8 check-DEJAGNUnormal9 check-DEJAGNUnormal10
> check-DEJAGNUnormal11 check-DEJAGNUnormal12 check-DEJAGNUnormal13
> check-DEJAGNUnormal14 check
> -DEJAGNUnormal15 check-DEJAGNUnormal16 check-DEJAGNUnormal17
> check-DEJAGNUnormal18 check-DEJAGNUnormal19 check-DEJAGNUnormal20
> check-DEJAGNUnormal21 check-D
> EJAGNUnormal22 check-DEJAGNUnormal23 check-DEJAGNUnormal24
> check-DEJAGNUnormal25 check-DEJAGNUnormal26 check-DEJAGNUnormal27
> check-DEJAGNUnormal28 check-DEJ
> AGNUnormal29 check-DEJAGNUnormal30 check-DEJAGNUnormal31
> check-DEJAGNUnormal32 check-DEJAGNUnormal33 check-DEJAGNUnormal34
> check-DEJAGNUnormal35 check-DEJAG
> NUnormal36 check-DEJAGNUnormal37 check-DEJAGNUnormal38
> check-DEJAGNUnormal39 check-DEJAGNUnormal40 check-DEJAGNUnormal41
> check-DEJAGNUnormal42 check-DEJAGNU
> normal43 check-DEJAGNUnormal44 check-DEJAGNUnormal45
> check-DEJAGNUnormal46 check-DEJAGNUnormal47 check-DEJAGNUnormal48
> check-DEJAGNUnormal49 check-DEJAGNUno
> rmal50 check-DEJAGNUnormal51 check-DEJAGNUnormal52
> check-DEJAGNUnormal53 check-DEJAGNUnormal54 check-DEJAGNUnormal55
> check-DEJAGNUnormal56 check-DEJAGNUnorm
> al57 check-DEJAGNUnormal58 check-DEJAGNUnormal59 check-DEJAGNUnormal60
> check-DEJAGNUnormal61 check-DEJAGNUnormal62 check-DEJAGNUnormal63
> check-DEJAGNUnormal
> 64 check-DEJAGNUnormal65 check-DEJAGNUnormal66 check-DEJAGNUnormal67
> check-DEJAGNUnormal68 check-DEJAGNUnormal69 check-DEJAGNUnormal70
> check-DEJAGNUnormal71
> check-DEJAGNUnormal72 check-DEJAGNUnormal73 check-DEJAGNUnormal74
> check-DEJAGNUnormal75 check-DEJAGNUnormal76 check-DEJAGNUnormal77
> check-DEJAGNUnormal78 c
> heck-DEJAGNUnormal79 check-DEJAGNUnormal80 check-DEJAGNUnormal81
> check-DEJAGNUnormal82 check-DEJAGNUnormal83 check-DEJAGNUnormal84
> check-DEJAGNUnormal85 che
> ck-DEJAGNUnormal86 check-DEJAGNUnormal87 check-DEJAGNUnormal88
> check-DEJAGNUnormal89 check-DEJAGNUnormal90 check-DEJAGNUnormal91
> check-DEJAGNUnormal92 check
> -DEJAGNUnormal93 check-DEJAGNUnormal94 check-DEJAGNUnormal95
> check-DEJAGNUnormal96 check-DEJAGNUnormal97 check-DEJAGNUnormal98
> check-DEJAGNUnormal99 check-D
> EJAGNUnormal100 check-DEJAGNUnormal101 check-DEJAGNUnormal102
> check-DEJAGNUnormal103 check-DEJAGNUnormal104 check-DEJAGNUnormal105
> check-DEJAGNUnormal106 ch
> eck-DEJAGNUnormal107 check-DEJAGNUnormal108 check-DEJAGNUnormal109
> check-DEJAGNUnormal110 check-DEJAGNUnormal111 check-DEJAGNUnormal112
> check-DEJAGNUnormal1
> 13 check-DEJAGNUnormal114 check-DEJAGNUnormal115
> check-DEJAGNUnormal116 check-DEJAGNUnormal117 check-DEJAGNUnormal118
> check-DEJAGNUnormal119 check-DEJAGNUno
> rmal120 check-DEJAGNUnormal121 check-DEJAGNUnormal122
> check-DEJAGNUnormal123 check-DEJAGNUnormal124 check-DEJAGNUnormal125
> check-DEJAGNUnormal126 check-DEJA
> GNUnormal127 check-DEJAGNUnormal128; \
>  rm -rf normal-parallel || true; \
>  for idx in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
> 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
> 46 47 48 49 50 51
> 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74
> 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97
> 98 99 100 101 102
> 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119
> 120 121 122 123 124 125 126 127 128; do \
>if [ -d normal$idx ]; then \
>  mv -f normal$idx/libstdc++.sum normal$idx/libstdc++.sum.sep; \
>  mv -f normal$idx/libstdc++.log normal$idx/libstdc++.log.sep; \
>fi; \
>  done; \
>  /bin/sh 
> /home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/../../contrib/dg-extract-results.sh
> \
>normal[0-9]*/libstdc++.sum.sep > libstdc++.sum; \
>  /bin/sh 
> 

Re: [PATCH] libstdc++: Reduce output of 'make check'

[Eric Gallager via Gcc-patches]

Maybe use $(AM_V_at) instead? That would allow it to be controlled by
the --enable-silent-rules flag to configure, as well as make V=1 vs.
make V=0 too.

On Thu, Sep 7, 2023 at 9:32 AM Jonathan Wakely via Gcc-patches
 wrote:
>
> Any objections to this change?
>
> -- >8 --
>
> This removes the 39 lines of shell commands that get echoed when
> starting the testsuite. The fact that near the end of that output it
> prints `echo "WARNING: could not find \`runtest'" 1>&2; :;` makes it
> look like that warning is actually being shown the the user.
>
> Suppress echoing the recipe, so that users only see the actual output
> from the testsuite, not the makefile recipe as well.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/Makefile.am (check-DEJAGNU): Use @ in recipe.
> * testsuite/Makefile.in: Regenerate.
> ---
>  libstdc++-v3/testsuite/Makefile.am | 2 +-
>  libstdc++-v3/testsuite/Makefile.in | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/testsuite/Makefile.am 
> b/libstdc++-v3/testsuite/Makefile.am
> index 7adc5318192..4cee585fd8e 100644
> --- a/libstdc++-v3/testsuite/Makefile.am
> +++ b/libstdc++-v3/testsuite/Makefile.am
> @@ -117,7 +117,7 @@ $(check_DEJAGNU_normal_targets): check-DEJAGNUnormal%: 
> normal%/site.exp
>
>  # Run the testsuite in normal mode.
>  check-DEJAGNU $(check_DEJAGNU_normal_targets): check-DEJAGNU%: site.exp
> -   $(if $*,@)AR="$(AR)"; export AR; \
> +   @$(if $*,@)AR="$(AR)"; export AR; \
> RANLIB="$(RANLIB)"; export RANLIB; \
> if [ -z "$*" ] && [ -n "$(filter -j%, $(MFLAGS))" ]; then \
>   rm -rf normal-parallel || true; \
>

Re: RFC: Top level configure: Require a minimum version 6.8 texinfo

[Eric Gallager via Gcc-patches]

On Tue, Aug 29, 2023 at 11:23 AM Nick Clifton via Gcc-patches
 wrote:
>
> Hi Guys,
>
>   Currently the top level configure.ac file sets the minimum required
>   version of texinfo to be 4.7.  I would like to propose changing this
>   to 6.8.
>
>   The reason for the change is that the bfd documentation now needs at
>   least version 6.8 in order to build[1][2].  Given that 4.7 is now
>   almost 20 years old (it was released in April 2004), updating the
>   requirement to a newer version does seem reasonable.  On the other
>   hand 6.8 is quite new (it was released in March 2021), so a lot of
>   systems out there may not have it.
>
>   Thoughts ?
>

Just as a point of reference, but the default makeinfo shipped with
macOS (/usr/bin/makeinfo) is stuck at version 4.8 due to the whole
GPL3 transition. The other makeinfos that I have installed are:
- /usr/local/bin/makeinfo (built manually) is at version 6.7
- /opt/local/bin/makeinfo (from MacPorts) is at version 7.0.3
- /opt/sw/bin/makeinfo (from Fink) is broken for me currently, so I
can't get its version at the moment
- /opt/sw/opt/texinfo-legacy/bin/makeinfo (also from Fink, but as a
separate package) is at version 4.13
- /opt/iains/x86_64-apple-darwin19/gcc-7-5-toolchain/bin/makeinfo
(from Iain Sandoe's package I used for bootstrapping Ada) is at
version 6.7

So, from this survey, the makeinfo from MacPorts is the only one I'd
be able to build with currently if this change went through. I think
that's a sign that 6.8 is too new.
Eric

> Cheers
>   Nick
>
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=30703
> [2] https://sourceware.org/pipermail/binutils/2023-February/125943.html
>
> Suggested patch:
>
> diff --git a/configure.ac b/configure.ac
> index 01cfd017273..10bfef1c6c5 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -3678,10 +3678,10 @@ case " $build_configdirs " in
>*" texinfo "*) MAKEINFO='$$r/$(BUILD_SUBDIR)/texinfo/makeinfo/makeinfo' ;;
>*)
>  changequote(,)
> -# For an installed makeinfo, we require it to be from texinfo 4.7 or
> +# For an installed makeinfo, we require it to be from texinfo 6.8 or
>  # higher, else we use the "missing" dummy.
>  if ${MAKEINFO} --version \
> -   | egrep 'texinfo[^0-9]*(4\.([7-9]|[1-9][0-9])|[5-9]|[1-9][0-9])' 
> >/dev/null 2>&1; then
> +   | egrep 'texinfo[^0-9]*(6\.([8-9]|[1-9][0-9])|[7-9]|[1-9][0-9])' 
> >/dev/null 2>&1; then
>:
>  else
>MAKEINFO="$MISSING makeinfo"
>

Re: [PATCH] improve error for when /usr/include isn't found [PR90835]

[Eric Gallager via Gcc-patches]

On Thu, Aug 17, 2023 at 11:38 PM Eric Gallager  wrote:
>
> On Thu, Aug 17, 2023 at 4:05 PM Iain Sandoe  wrote:
> >
> > Hi Eric,
> >
> > thanks for working on this.
> >
> > > On 17 Aug 2023, at 20:35, Eric Gallager  wrote:
> > >
> > > This is a pretty simple patch that ought to help Darwin users understand
> > > better why their build is failing when they forget to pass the
> > > --with-sysroot= flag to configure.
> > >
> > > gcc/ChangeLog:
> > >
> > >PR target/90835
> > >* Makefile.in: improve error message when /usr/include is
> > >missing
> >
> > 1. the main issue with this approach is that the error does not happen 
> > until after the
> >user has waited for the whole of the stage 1 build.
> >
> >(I had in mind the idea that top level configure can identify that the 
> > platform
> > is Darwin, and that there is no sysroot configured;
> >  then [for bootstrap] complain if there is no /use/include
> >  els [for non-bootstrap] complain always)
> >
> > - this would mean that the fail occurs at initial configure time.
> >
> > 2. if we went with this patch as an incremental improvement:
> >
> > + case ${build_os} in \
> > +   darwin*) \
> > + echo "(on darwin this usually means you need to pass the 
> > --with-sysroot flag to configure to point it to where the system headers 
> > are actually put)" >&2; \
> >
> > I think we need to put this in terms that relate to the system and things 
> > the user can find, so ;
> > “on Darwin this usually means you need to pass the --with-sysroot= flag to 
> > point to a valid MacOS SDK”
> >
>
> OK, so would it be ok with that change in wording?
>
> > (In practice, the headers cause the first fail, but we also need to find 
> > the libraries when linking)
> >
> > Iain
> >

Committed with your proposed change in wording as
r14-3335-g9a5d1fceb86a61:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9a5d1fceb86a61c9ead380df89ce3c4ba387d2e5
(Jeff approved in reply to one of the other copies)

Re: [PATCH] improve error when /usr/include isn't found [PR90835]

[Eric Gallager via Gcc-patches]

Thanks, I committed the version with Iain's suggested change in wording:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627796.html
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9a5d1fceb86a61c9ead380df89ce3c4ba387d2e5
(sorry that this got sent multiple times; I thought the email hadn't
gone through properly...)

On Sat, Aug 19, 2023 at 4:11 PM Jeff Law  wrote:
>
>
>
> On 8/17/23 12:59, Eric Gallager via Gcc-patches wrote:
> > Subject:
> > [PATCH] improve error when /usr/include isn't found [PR90835]
> > From:
> > Eric Gallager via Gcc-patches 
> > Date:
> > 8/17/23, 12:59
> >
> > To:
> > gcc-patches@gcc.gnu.org
> > CC:
> > ia...@gcc.gnu.org, Eric Gallager 
> >
> >
> > This is a pretty simple patch that ought to help Darwin users understand
> > better why their build is failing when they forget to pass the
> > --with-sysroot= flag to configure.
> >
> > gcc/ChangeLog:
> >
> >  PR target/90835
> >  * Makefile.in: improve error message when /usr/include is
> >  missing
> OK.
> jeff

[PATCH] improve error when /usr/include isn't found [PR90835]

[Eric Gallager via Gcc-patches]

This is a pretty simple patch that ought to help Darwin users understand
better why their build is failing when they forget to pass the
--with-sysroot= flag to configure.

gcc/ChangeLog:

PR target/90835
* Makefile.in: improve error message when /usr/include is
missing
---
 gcc/Makefile.in | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 97e5450ecb5..535c475dfab 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -55,6 +55,7 @@ MAKEOVERRIDES =
 # ---
 
 build=@build@
+build_os=@build_os@
 host=@host@
 host_noncanonical=@host_noncanonical@
 host_os=@host_os@
@@ -3240,8 +3241,13 @@ stmp-fixinc: gsyslimits.h macro_list fixinc_list \
multi_dir=`echo $${ml} | sed -e 's/^[^;]*;//'`; \
fix_dir=include-fixed$${multi_dir}; \
if ! $(inhibit_libc) && test ! -d ${BUILD_SYSTEM_HEADER_DIR}; then \
- echo The directory that should contain system headers does not 
exist: >&2 ; \
+ echo "The directory (BUILD_SYSTEM_HEADER_DIR) that should contain 
system headers does not exist:" >&2 ; \
  echo "  ${BUILD_SYSTEM_HEADER_DIR}" >&2 ; \
+ case ${build_os} in \
+   darwin*) \
+ echo "(on darwin this usually means you need to pass the 
--with-sysroot flag to configure to point it to where the system headers are 
actually put)" >&2; \
+ ;; \
+ esac; \
  tooldir_sysinc=`echo "${gcc_tooldir}/sys-include" | sed -e :a -e 
"s,[^/]*/\.\.\/,," -e ta`; \
  if test "x${BUILD_SYSTEM_HEADER_DIR}" = "x$${tooldir_sysinc}"; \
  then sleep 1; else exit 1; fi; \
-- 
2.32.0 (Apple Git-132)

[PATCH] improve error when /usr/include isn't found [PR90835]

[Eric Gallager via Gcc-patches]

This is a pretty simple patch that ought to help Darwin users understand
better why their build is failing when they forget to pass the
--with-sysroot= flag to configure.

gcc/ChangeLog:

PR target/90835
* Makefile.in: improve error message when /usr/include is
missing
---
 gcc/Makefile.in | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 97e5450ecb5..535c475dfab 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -55,6 +55,7 @@ MAKEOVERRIDES =
 # ---
 
 build=@build@
+build_os=@build_os@
 host=@host@
 host_noncanonical=@host_noncanonical@
 host_os=@host_os@
@@ -3240,8 +3241,13 @@ stmp-fixinc: gsyslimits.h macro_list fixinc_list \
multi_dir=`echo $${ml} | sed -e 's/^[^;]*;//'`; \
fix_dir=include-fixed$${multi_dir}; \
if ! $(inhibit_libc) && test ! -d ${BUILD_SYSTEM_HEADER_DIR}; then \
- echo The directory that should contain system headers does not 
exist: >&2 ; \
+ echo "The directory (BUILD_SYSTEM_HEADER_DIR) that should contain 
system headers does not exist:" >&2 ; \
  echo "  ${BUILD_SYSTEM_HEADER_DIR}" >&2 ; \
+ case ${build_os} in \
+   darwin*) \
+ echo "(on darwin this usually means you need to pass the 
--with-sysroot flag to configure to point it to where the system headers are 
actually put)" >&2; \
+ ;; \
+ esac; \
  tooldir_sysinc=`echo "${gcc_tooldir}/sys-include" | sed -e :a -e 
"s,[^/]*/\.\.\/,," -e ta`; \
  if test "x${BUILD_SYSTEM_HEADER_DIR}" = "x$${tooldir_sysinc}"; \
  then sleep 1; else exit 1; fi; \
-- 
2.32.0 (Apple Git-132)

[PATCH] improve error for when /usr/include isn't found [PR90835]

[Eric Gallager via Gcc-patches]

This is a pretty simple patch that ought to help Darwin users understand
better why their build is failing when they forget to pass the
--with-sysroot= flag to configure.

gcc/ChangeLog:

PR target/90835
* Makefile.in: improve error message when /usr/include is
missing


0001-improve-error-for-when-usr-include-isn-t-found.patch
Description: Binary data

[PING] Re: [PATCH v2] Re: [WIP] Have -Wpointer-sign be enabled by -Wextra, too [PR109836]

[Eric Gallager via Gcc-patches]

PING

On Tue, Aug 8, 2023 at 8:17 PM Eric Gallager  wrote:
>
> On Tue, May 30, 2023 at 5:42 PM Eric Gallager  wrote:
> >
> > PR109836 is a request to have -Wpointer-sign enabled by default. There
> > were points of disagreement raised in the bug report, so I figured
> > that maybe as a compromise, the warning could just be enabled by
> > -Wextra, as well (I have in fact seen some projects that enable
> > -Wextra but not -Wall). This patch would implement my suggestion of
> > adding it to -Wextra, but it's not ready to commit yet, as it still
> > needs testing, documentation, and a ChangeLog entry. I'm just posting
> > it here as an RFC; what do people think?
>
> Here's the link for the previous message's spot in the archives:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620137.html
> Here's an updated (but still untested) version of the patch with an 
> invoke.texi
> update and a ChangeLog entry:
>
> gcc/c-family/ChangeLog:
>
> * c.opt: Have -Wpointer-sign be enabled by -Wextra, too
>
> gcc/ChangeLog:
>
> * doc/invoke.texi: Document -Wpointer-sign now being enabled by -Wextra, 
> too

[PATCH v2] Re: [WIP] Have -Wpointer-sign be enabled by -Wextra, too [PR109836]

[Eric Gallager via Gcc-patches]

On Tue, May 30, 2023 at 5:42 PM Eric Gallager  wrote:
>
> PR109836 is a request to have -Wpointer-sign enabled by default. There
> were points of disagreement raised in the bug report, so I figured
> that maybe as a compromise, the warning could just be enabled by
> -Wextra, as well (I have in fact seen some projects that enable
> -Wextra but not -Wall). This patch would implement my suggestion of
> adding it to -Wextra, but it's not ready to commit yet, as it still
> needs testing, documentation, and a ChangeLog entry. I'm just posting
> it here as an RFC; what do people think?

Here's the link for the previous message's spot in the archives:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620137.html
Here's an updated (but still untested) version of the patch with an invoke.texi
update and a ChangeLog entry:

gcc/c-family/ChangeLog:

* c.opt: Have -Wpointer-sign be enabled by -Wextra, too

gcc/ChangeLog:

* doc/invoke.texi: Document -Wpointer-sign now being enabled by -Wextra, too


patch_Wpointer-sign_Wextra.diff
Description: Binary data

Re: [PATCH 06/24] toplevel: Recover tilegx/tilepro targets

[Eric Gallager via Gcc-patches]

On Mon, Aug 7, 2023 at 1:43 PM Jeff Law via Gcc-patches
 wrote:
> On 8/7/23 04:32, Arsen Arsenović via Gcc-patches wrote:
> > These are still supported in Binutils.
> >
> > ChangeLog:
> >
> >   * configure: Regenerate.
> >   * configure.ac: Recover tilegx/tilepro targets.
> OK.  Good reminder that if we deprecate/remove something from GCC, we
> probably want to keep the toplevel configure bits for other projects
> that use the toplevel configure.
>
> jeff

Maybe it's worth adding a comment in the script to remind people of this?

Re: [PATCH 03/24] gcc-4.5 build fixes

[Eric Gallager via Gcc-patches]

On Mon, Aug 7, 2023 at 7:22 AM Arsen Arsenović via Gcc-patches
 wrote:
>
> From: Alan Modra 
>
> Trying to build binutils with an older gcc currently fails.  Working
> around these gcc bugs is not onerous so let's fix them.
>
> include/ChangeLog:
>
> * xtensa-dynconfig.h (xtensa_isa_internal): Delete unnecessary
> forward declaration.
> ---
>  include/xtensa-dynconfig.h | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/include/xtensa-dynconfig.h b/include/xtensa-dynconfig.h
> index 48877ebb6b6..45d54dcd0e0 100644
> --- a/include/xtensa-dynconfig.h
> +++ b/include/xtensa-dynconfig.h
> @@ -121,8 +121,6 @@ struct xtensa_config_v4
>int xchal_unaligned_store_hw;
>  };
>
> -typedef struct xtensa_isa_internal_struct xtensa_isa_internal;
> -
>  extern const void *xtensa_load_config (const char *name,
>const void *no_plugin_def,
>const void *no_name_def);
> --
> 2.41.0
>

Just to be clear: is it just gcc-4.5 where this fails, or gcc-4.5 and
all versions prior to it as well?

Re: [PATCH 00/24] Sync shared build infrastructure with binutils-gdb

[Eric Gallager via Gcc-patches]

On Mon, Aug 7, 2023 at 7:19 AM Arsen Arsenović via Gcc-patches
 wrote:
>
> Hello,
>
> This patch set, combined with a sibling patch set sent on the binutils
> and GDB MLs, bring up the shared infrastructure between the two projects
> in sync again.
>
> It largely consists of cherry-picks from various people which have been
> reviewed and accepted on the binutils-gdb side, as well as a couple of
> patches for differences that seemed to get lost during the
> pick-and-regenerate process, though I've had to reformat quite a few
> commits so that they match what the changelog verifier expects.
>
> Some of these commits were previously applied and then reverted, namely
> "Check if AR works with --plugin and rc", but the reversion reason[1]
> seems to be no longer valid as of requiring Binutils 2.35 for LTO
> anyway.
>
> In addition, I'm not entirely certain that the handling of the removed
> targets I re-added is correct, nor what their status in binutils and gdb
> is, so feedback is welcome there.
>
> During this process, it appears that I overlooked passing -x to
> cherry-pick, so the paper trail got lost.  If needed, I can hack
> together some code to associate commits based on subjects with their
> pair in the other repository, and amend the commits with these
> references added.
>
> These patches ignore the intl/ directory, as I plan to follow up this
> patchset with one that can be cleanly applied to both trees which gets
> rid of the intl/ directory in favor of out-of-tree gettext (ISL, GMP, et
> al. style).
>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>
> OK for master?
>
> Thanks in advance, have a lovely day.
>
> [1]: 
> https://inbox.sourceware.org/gcc-patches/CAMe9rOqFSOSM5Sw5SBMiy20rdgRJkftUXdw=ykexhvdmuty...@mail.gmail.com/
>
> Alan Modra (4):
>   PR29961, plugin-api.h: "Could not detect architecture endianess"
>   gcc-4.5 build fixes
>   egrep in binutils
>   PR27116, Spelling errors found by Debian style checker
>
> Alexander von Gluck IV (1):
>   Add support for the haiku operating system
>
> Arsen Arsenović (3):
>   toplevel: Substitute GDCFLAGS instead of using CFLAGS
>   toplevel: Recover tilegx/tilepro targets
>   configure: reinstate 32b PA-RISC HP-UX target in toplevel
>
> Christophe Lyon (1):
>   configure: require libzstd >= 1.4.0
>
> Fangrui Song (1):
>   binutils, gdb: support zstd compressed debug sections
>
> H.J. Lu (4):
>   Sync with binutils: GCC: Pass --plugin to AR and RANLIB
>   GCC: Check if AR works with --plugin and rc
>   PKG_CHECK_MODULES: Check if $pkg_cv_[]$1[]_LIBS works
>   PKG_CHECK_MODULES: Properly check if $pkg_cv_[]$1[]_LIBS works
>
> Indu Bhagat (2):
>   bfd: linker: merge .sframe sections
>   toplevel: Makefile.def: add install-strip dependency on libsframe
>
> John Ericson (1):
>   Deprecate a.out support for NetBSD targets.
>
> Luis Machado (1):
>   Disable year 2038 support on 32-bit hosts by default
>
> Martin Liska (1):
>   add --enable-default-compressed-debug-sections-algorithm configure
> option
>
> Nick Alcock (3):
>   libtool.m4: fix nm BSD flag detection
>   libtool.m4: fix the NM="/nm/over/here -B/option/with/path" case
>   libtool.m4: augment symcode for Solaris 11
>
> Simon Marchi (1):
>   Pass PKG_CONFIG_PATH down from top-level Makefile
>
> Vladimir Mezentsev (1):
>   gprofng: a new GNU profiler
>
>  Makefile.def   |  18 ++
>  Makefile.in| 517 -
>  Makefile.tpl   |  10 +-
>  config/gcc-plugin.m4   |  40 +++
>  config/lib-ld.m4   |   8 +-
>  config/override.m4 |   2 +-
>  config/picflag.m4  |   4 +-
>  config/pkg.m4  |   8 +
>  config/zstd.m4 |  23 ++
>  configure  | 224 +++-
>  configure.ac   |  74 +-
>  fixincludes/configure  |   3 +-
>  gcc/configure  | 140 ++
>  include/collectorAPI.h |  73 ++
>  include/libcollector.h |  89 +++
>  include/libfcollector.h|  42 +++
>  include/plugin-api.h   |  49 ++--
>  include/xtensa-dynconfig.h |   2 -
>  intl/configure |   4 +-
>  libada/configure   |   4 +-
>  libatomic/configure| 130 ++
>  libbacktrace/configure | 130 ++
>  libcc1/configure   | 132 ++
>  libcpp/configure   |   4 +-
>  libffi/configure   | 132 ++
>  libgcc/configure   |   6 +-
>  libgfortran/configure  | 132 ++
>  libgm2/configure   | 132 ++
>  libgomp/configure  | 132 ++
>  libiberty/Makefile.in  |   5 +-
>  libiberty/aclocal.m4   |   1 +
>  libiberty/configure| 144 ++-
>  libiberty/configure.ac |  12 +
>  libitm/configure   | 132 ++
>  libobjc/configure  | 130 ++
>  libphobos/configure| 130 ++
>  libquadmath/configure  | 130 ++
>  libsanitizer/configure | 132 ++
>  

Re: [PATCH] c++: provide #include hint for missing includes [PR110164]

[Eric Gallager via Gcc-patches]

On Wed, Jun 14, 2023 at 8:29 PM David Malcolm via Gcc-patches
 wrote:
>
> PR c++/110164 notes that in cases where we have a forward decl
> of a std library type such as:
>
> std::array x;
>
> we omit this diagnostic:
>
> error: aggregate ‘std::array x’ has incomplete type and cannot be 
> defined
>
> This patch adds this hint to the diagnostic:
>
> note: ‘std::array’ is defined in header ‘’; this is probably fixable 
> by adding ‘#include ’
>

..."probably"?

> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> OK for trunk?
>
> gcc/cp/ChangeLog:
> PR c++/110164
> * cp-name-hint.h (maybe_suggest_missing_header): New decl.
> * decl.cc: Define INCLUDE_MEMORY.  Add include of
> "cp/cp-name-hint.h".
> (start_decl_1): Call maybe_suggest_missing_header.
> * name-lookup.cc (maybe_suggest_missing_header): Remove "static".
>
> gcc/testsuite/ChangeLog:
> PR c++/110164
> * g++.dg/missing-header-pr110164.C: New test.
> ---
>  gcc/cp/cp-name-hint.h  |  3 +++
>  gcc/cp/decl.cc | 10 ++
>  gcc/cp/name-lookup.cc  |  2 +-
>  gcc/testsuite/g++.dg/missing-header-pr110164.C | 10 ++
>  4 files changed, 24 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/g++.dg/missing-header-pr110164.C
>
> diff --git a/gcc/cp/cp-name-hint.h b/gcc/cp/cp-name-hint.h
> index bfa7c53c8f6..e2387e23d1f 100644
> --- a/gcc/cp/cp-name-hint.h
> +++ b/gcc/cp/cp-name-hint.h
> @@ -32,6 +32,9 @@ along with GCC; see the file COPYING3.  If not see
>
>  extern name_hint suggest_alternatives_for (location_t, tree, bool);
>  extern name_hint suggest_alternatives_in_other_namespaces (location_t, tree);
> +extern name_hint maybe_suggest_missing_header (location_t location,
> +  tree name,
> +  tree scope);
>  extern name_hint suggest_alternative_in_explicit_scope (location_t, tree, 
> tree);
>  extern name_hint suggest_alternative_in_scoped_enum (tree, tree);
>
> diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
> index a672e4844f1..504b08ec250 100644
> --- a/gcc/cp/decl.cc
> +++ b/gcc/cp/decl.cc
> @@ -27,6 +27,7 @@ along with GCC; see the file COPYING3.  If not see
> line numbers.  For example, the CONST_DECLs for enum values.  */
>
>  #include "config.h"
> +#define INCLUDE_MEMORY
>  #include "system.h"
>  #include "coretypes.h"
>  #include "target.h"
> @@ -46,6 +47,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "c-family/c-objc.h"
>  #include "c-family/c-pragma.h"
>  #include "c-family/c-ubsan.h"
> +#include "cp/cp-name-hint.h"
>  #include "debug.h"
>  #include "plugin.h"
>  #include "builtins.h"
> @@ -5995,7 +5997,11 @@ start_decl_1 (tree decl, bool initialized)
> ;   /* An auto type is ok.  */
>else if (TREE_CODE (type) != ARRAY_TYPE)
> {
> + auto_diagnostic_group d;
>   error ("variable %q#D has initializer but incomplete type", decl);
> + maybe_suggest_missing_header (input_location,
> +   TYPE_IDENTIFIER (type),
> +   TYPE_CONTEXT (type));
>   type = TREE_TYPE (decl) = error_mark_node;
> }
>else if (!COMPLETE_TYPE_P (complete_type (TREE_TYPE (type
> @@ -6011,8 +6017,12 @@ start_decl_1 (tree decl, bool initialized)
> gcc_assert (CLASS_PLACEHOLDER_TEMPLATE (type));
>else
> {
> + auto_diagnostic_group d;
>   error ("aggregate %q#D has incomplete type and cannot be defined",
>  decl);
> + maybe_suggest_missing_header (input_location,
> +   TYPE_IDENTIFIER (type),
> +   TYPE_CONTEXT (type));
>   /* Change the type so that assemble_variable will give
>  DECL an rtl we can live with: (mem (const_int 0)).  */
>   type = TREE_TYPE (decl) = error_mark_node;
> diff --git a/gcc/cp/name-lookup.cc b/gcc/cp/name-lookup.cc
> index 6ac58a35b56..917b481c163 100644
> --- a/gcc/cp/name-lookup.cc
> +++ b/gcc/cp/name-lookup.cc
> @@ -6796,7 +6796,7 @@ maybe_suggest_missing_std_header (location_t location, 
> tree name)
> for NAME within SCOPE at LOCATION, or an empty name_hint if this isn't
> applicable.  */
>
> -static name_hint
> +name_hint
>  maybe_suggest_missing_header (location_t location, tree name, tree scope)
>  {
>if (scope == NULL_TREE)
> diff --git a/gcc/testsuite/g++.dg/missing-header-pr110164.C 
> b/gcc/testsuite/g++.dg/missing-header-pr110164.C
> new file mode 100644
> index 000..15980071c38
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/missing-header-pr110164.C
> @@ -0,0 +1,10 @@
> +// { dg-require-effective-target c++11 }
> +
> +#include 
> +
> +std::array a1; /* { dg-error "incomplete type" } */
> +/* { dg-message 

Re: [RFC] Add stdckdint.h header for C23

[Eric Gallager via Gcc-patches]

On Sat, Jun 10, 2023 at 6:38 AM Jakub Jelinek via Gcc-patches
 wrote:
>
> Hi!
>
> The following patch is an attempt to implement the C23 stdckdint.h
> header on top of our GNU extension - __builtin_{add,sub,mul}_overflow
> builtins.
>
> I have looked at gnulib stdckdint.h and they are full of workarounds
> for various compilers, EDG doesn't do this, clang <= 14 can't multiply
> __int128, ..., so I think the header belongs into the compiler rather
> than C library, because it would be a nightmare to maintain it there.
>
> What I'm struggling with is enforcing the weird restrictions
> C23 imposes on these.
>
> The builtins error on the result pointer not being writable, or
> having boolean or enumeral type (the reason for disallowing bool
> was that it would be questionable whether it should act as if
> storing to an unsigned 1-bit precision type which would overflow
> if result is not in [0,1] or whether it would never overflow
> for bool * result and simply store false if the infinite precision
> result is 0 and true otherwise, and for enums because of the
> uncertainities on just the enumerators vs. range from smallest to
> largest enumerator vs. strict enum precision with underlying type).
> They do allow storing result in plain char.  And the source operands
> can have any integral types, including plain char, including booleans
> and including enumeral types.  The plain is to allow even _BitInt(N)
> as both source and result later on.
>
> Now, C23 says that suitable types for both type2/type3 and type1
> are integral types other than plain char, bool, a bit-precise integer type,
> or an enumerated type.
>
> And it also says:
> It is recommended to produce a diagnostic message if type2 or type3 are
> not suitable integer types, or if *result is not a modifiable lvalue of
> a suitable integer type.
>
> I've tried to first check it with:
>   static_assert (_Generic ((a), char: 0, const char: 0, volatile char: 0, 
> const volatile char: 0,
>default: __builtin_classify_type (a) - 1 <= 1U),
>  "...")
> but that only catches plain char and doesn't catch _Bool/bool and
> doesn't catch enumerated types (note, for the *result we diagnose
> it for the builtins, but not for the other args), because
> __builtin_classify_type sadly promotes its argument.
>
> The _Generic in the patch below is slightly better, it catches
> also _Bool/bool, but doesn't catch enumerated types, comptypes
> used by _Generic says enumeral type is compatible with the underlying
> integer type.  But catching just plain char and bool would be
> also doable with just _Generic listing the non-allowed types.
>
> I think changing __builtin_classify_type behavior after 35 years
> would be dangerous, shall we introduce a new similar builtin which
> would just never promote the argument/perform array/function/enum
> conversions on it, so that
> __builtin_type_classify (true) == boolean_type_class
> enum E { E1, E2 } e;
> __builtin_type_classify (e) == enumeral_type_class
> int a[2];
> __builtin_type_classify (a) == array_type_class
> etc.?
> Seems clang changed __builtin_type_classify at some point
> so that it e.g. returns enumeral_type_class for enum arguments
> and array_type_class for arrays, but doesn't return boolean_type_class
> for _Bool argument.
>
> Also, shall we introduce __typeof_unqual__ keyword which could be used in
> < C23 modes and perhaps C++?
>

I think I remember a desire for a __typeof_unqual__ keyword in other
contexts as well, too, so it would probably be worthwhile anyways...

> 2023-06-10  Jakub Jelinek  
>
> * Makefile.in (USER_H): Add stdckdint.h.
> * ginclude/stdckdint.h: New file.
>
> * gcc.dg/stdckdint-1.c: New test.
> * gcc.dg/stdckdint-2.c: New test.
>
> --- gcc/Makefile.in.jj  2023-06-06 20:02:35.581211930 +0200
> +++ gcc/Makefile.in 2023-06-10 10:17:05.062270115 +0200
> @@ -466,6 +466,7 @@ USER_H = $(srcdir)/ginclude/float.h \
>  $(srcdir)/ginclude/stdnoreturn.h \
>  $(srcdir)/ginclude/stdalign.h \
>  $(srcdir)/ginclude/stdatomic.h \
> +$(srcdir)/ginclude/stdckdint.h \
>  $(EXTRA_HEADERS)
>
>  USER_H_INC_NEXT_PRE = @user_headers_inc_next_pre@
> --- gcc/ginclude/stdckdint.h.jj 2023-06-10 09:20:39.154053338 +0200
> +++ gcc/ginclude/stdckdint.h2023-06-10 12:02:33.454947780 +0200
> @@ -0,0 +1,78 @@
> +/* Copyright (C) 2023 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.
> +
> +Under Section 7 of GPL version 3, you 

[WIP] Have -Wpointer-sign be enabled by -Wextra, too [PR109836]

[Eric Gallager via Gcc-patches]

PR109836 is a request to have -Wpointer-sign enabled by default. There
were points of disagreement raised in the bug report, so I figured
that maybe as a compromise, the warning could just be enabled by
-Wextra, as well (I have in fact seen some projects that enable
-Wextra but not -Wall). This patch would implement my suggestion of
adding it to -Wextra, but it's not ready to commit yet, as it still
needs testing, documentation, and a ChangeLog entry. I'm just posting
it here as an RFC; what do people think?


patch-gcc_c-family_c.opt.diff
Description: Binary data

Re: [PATCH][stage1] Remove conditionals around free()

[Eric Gallager via Gcc-patches]

On 3/4/23, Janne Blomqvist via Gcc-patches  wrote:
> On Wed, Mar 1, 2023 at 11:31 PM Bernhard Reutner-Fischer via Fortran
>  wrote:
>>
>> Hi!
>>
>> Mere cosmetics.
>>
>> - if (foo != NULL)
>> free (foo);
>>
>> With the caveat that coccinelle ruins replacement whitespace or i'm
>> uneducated enough to be unable to _not_ run the diff through
>>  sed -e 's/^+\([[:space:]]*\)free(/+\1free (/'
>> at least. If anybody knows how to improve replacement whitespace,
>> i'd be interrested but didn't look nor ask. ISTM that leading
>> whitespace is somewhat ruined, too, so beware (8 spaces versus tab as
>> far as i have spot-checked).
>>
>> Would touch
>>  gcc/ada/rtinit.c |3 +--
>>  intl/bindtextdom.c   |3 +--
>>  intl/loadmsgcat.c|6 ++
>>  intl/localcharset.c  |3 +--
>>  libbacktrace/xztest.c|9 +++--
>>  libbacktrace/zstdtest.c  |9 +++--
>>  libbacktrace/ztest.c |9 +++--
>>  libgfortran/caf/single.c |6 ++
>>  libgfortran/io/async.c   |6 ++
>>  libgfortran/io/format.c  |3 +--
>>  libgfortran/io/transfer.c|6 ++
>>  libgfortran/io/unix.c|3 +--
>>  libgo/runtime/go-setenv.c|6 ++
>>  libgo/runtime/go-unsetenv.c  |3 +--
>>  libgomp/target.c |3 +--
>>  libiberty/concat.c   |3 +--
>>  zlib/contrib/minizip/unzip.c |2 +-
>>  zlib/contrib/minizip/zip.c   |2 +-
>>  zlib/examples/enough.c   |6 ++
>>  zlib/examples/gun.c  |2 +-
>>  zlib/examples/gzjoin.c   |3 +--
>>  zlib/examples/gzlog.c|6 ++
>>
>> coccinelle script and invocation inline.
>> Would need to be split for the respective maintainers and run through
>> mklog with subject changelog and should of course be compiled and
>> tested before that.
>>
>> Remarks:
>> 1) We should do this in if-conversion (?) on our own.
>>I suppose. Independently of -fdelete-null-pointer-checks
>> 2) Maybe not silently, but raise language awareness nowadays.
>>By now it's been a long time since this was first mandated.
>> 3) fallout from looking at something completely different
>> 4) i most likely will not remember to split it apart and send proper
>>patches, tested patches, in stage 1 to maintainers proper, so if
>>anyone feels like pursuing this, be my guest. I thought i'd just
>>mention it.
>>
>> cheers,
>
> Back in 2011 Jim Meyering applied a patch doing this, see
> https://gcc.gnu.org/legacy-ml/gcc-patches/2011-03/msg00403.html , and
> the gcc/README.Portability snippet added then which is still there.
>
> Per analysis done then, it seems SunOS 4 was the last system where
> free() of a NULL pointer didn't behave per the spec.
>
> Also in Jim's patch intl/ and zlib/ directories were not touched as
> those are imported from other upstreams.
>

Speaking of which, this reminded me that I opened bug 80528 to catch
code like this as a compiler warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80528

> --
> Janne Blomqvist
>

[PATCH] Silence some -Wnarrowing errors

[Eric Gallager via Gcc-patches]

I tried turning -Wnarrowing back on earlier this year, but
unfortunately it didn't work due to triggering a bunch of new errors.
This patch silences at least some of them, but there will still be
more left even after applying it. (When compiling with clang,
technically the warning flag is -Wc++11-narrowing, but it's pretty
much the same thing as gcc's -Wnarrowing, albeit with fixit hints,
which I made use of to insert the casts here.)

gcc/ChangeLog:

* ipa-modref.cc (modref_lattice::add_escape_point): Use a
static_cast to silence -Wnarrowing.
(modref_eaf_analysis::record_escape_points): Likewise.
(update_escape_summary_1): Likewise.
* rtl-ssa/changes.cc (function_info::temp_access_array): Likewise.
* rtl-ssa/member-fns.inl: Likewise.
* tree-ssa-structalias.cc (push_fields_onto_fieldstack): Likewise.
* tree-vect-slp.cc (vect_prologue_cost_for_slp): Likewise.
* tree-vect-stmts.cc (vect_truncate_gather_scatter_offset): Likewise.
(vectorizable_operation): Likewise.


patch-Wnarrowing.diff
Description: Binary data

Re: [PATCH] Fix PR59447: include "(or later)" in documentation of --with-dwarf2 configure flag

[Eric Gallager via Gcc-patches]

On Fri, Dec 2, 2022 at 12:30 AM Sandra Loosemore
 wrote:
>
> On 12/1/22 20:29, Eric Gallager via Gcc-patches wrote:
> > A pretty simple patch; borrowed from Andrew Pinski on bugzilla:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
> > Tested by doing `./configure --help` in the gcc subdirectory and
> > noting that the "(or later)" made it into the output. OK for trunk?
> >
> > gcc/ChangeLog:
> >
> >  PR bootstrap/59447
> >  * configure: Regenerate.
> >  * configure.ac: Document --with-dwarf2 flag as also applying to
> > later DWARF standards.
> >  * doc/install.texi: Likewise.
>
> Hmmm.  In this hunk
>
> > diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> > index 589c64965b2..1d7c73eb914 100644
> > --- a/gcc/doc/install.texi
> > +++ b/gcc/doc/install.texi
> > @@ -1914,7 +1914,7 @@ should not be built.
> >
> >  @item --with-dwarf2
> >  Specify that the compiler should
> > -use DWARF 2 debugging information as the default.
> > +use DWARF 2 (or later) debugging information as the default.
> >
> >  @item --with-advance-toolchain=@var{at}
> >  On 64-bit PowerPC Linux systems, configure the compiler to use the
>
> I think it would be better to say
>
> use DWARF format for debugging information as the default; the exact
> DWARF version that is the default is target-specific.
>
> OK with that change.

OK thanks, committed as r13-4457-ga710f3ce747479.

>
> -Sandra

[PATCH] Fix PR59447: include "(or later)" in documentation of --with-dwarf2 configure flag

[Eric Gallager via Gcc-patches]

A pretty simple patch; borrowed from Andrew Pinski on bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447
Tested by doing `./configure --help` in the gcc subdirectory and
noting that the "(or later)" made it into the output. OK for trunk?

gcc/ChangeLog:

PR bootstrap/59447
* configure: Regenerate.
* configure.ac: Document --with-dwarf2 flag as also applying to
later DWARF standards.
* doc/install.texi: Likewise.


patch-PR59447.diff
Description: Binary data

Re: [PATCH] docs: document sanitizers can trigger warnings

[Eric Gallager via Gcc-patches]

On Wed, Oct 26, 2022 at 7:09 AM Martin Liška  wrote:
>
> PR sanitizer/107298
>
> gcc/ChangeLog:
>
> * doc/invoke.texi: Document sanitizers can trigger warnings.
> ---
>  gcc/doc/invoke.texi | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 64f77e8367a..1ffbba16a72 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -16460,6 +16460,10 @@ by this option.
>
>  @end table
>
> +Note the enabled sanitizer options tend to increase a false-positive rate
> +of selected warnings, most notably @option{-Wmaybe-uninitialized}.
> +And thus we recommend to disable @option{-Werror}.
> +

I'd recommend rewording the second sentence there as:
"Thus, GCC developers recommend disabling @option{-Werror} when using
sanitizer options."

>  While @option{-ftrapv} causes traps for signed overflows to be emitted,
>  @option{-fsanitize=undefined} gives a diagnostic message.
>  This currently works only for the C family of languages.
> --
> 2.38.0
>

Re: [PATCH v2 2/3] doc: -falign-functions is ignored under -Os

[Eric Gallager via Gcc-patches]

On Tue, Oct 11, 2022 at 5:03 PM Palmer Dabbelt  wrote:
>
> This is implicitly mentioned in the docs, but there were some questions
> in a recent patch.  This makes it more exlicit that -falign-functions is
> meant to be ignored under -Os.
>
> gcc/doc/ChangeLog
>
> * invoke.texi (-falign-functions): Mention -Os

Since there's -Oz now, too, should that be mentioned as well?

> ---
>  gcc/doc/invoke.texi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 8326a60dcf1..a24798d5029 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -13164,7 +13164,8 @@ equivalent and mean that functions are not aligned.
>  If @var{n} is not specified or is zero, use a machine-dependent default.
>  The maximum allowed @var{n} option value is 65536.
>
> -Enabled at levels @option{-O2}, @option{-O3}.
> +Enabled at levels @option{-O2}, @option{-O3}.  This has no behavior under 
> under
> +@option{-Os}.
>
>  @item -flimit-function-alignment
>  If this option is enabled, the compiler tries to avoid unnecessarily
> --
> 2.34.1
>

Re: [PATCH] Add --without-makeinfo

[Eric Gallager via Gcc-patches]

On Tue, Oct 4, 2022 at 11:22 AM Tom de Vries via Gcc-patches
 wrote:
>
> Hi,
>
> Currently, we cannot build gdb without makeinfo installed.
>
> It would be convenient to work around this by using the configure flag
> MAKEINFO=/usr/bin/true or some such, but that doesn't work because top-level
> configure requires a makeinfo of at least version 4.7, and that version check
> fails for /usr/bin/true, so we end up with MAKEINFO=missing instead.
>
> What does work is this:
> ...
> $ ./configure
> $ make MAKEINFO=/usr/bin/true
> ...
> but the drawback is that it'll have to be specified for each make invocation.
>
> Fix this by adding support for --without-makeinfo in top-level configure.
>
> Tested by building gdb on x86_64-linux, and verifying that no .info files
> were generated.
>
> OK for trunk?
>
> Thanks,
> - Tom
>
> Add --without-makeinfo
>
> ChangeLog:
>
> 2022-09-05  Tom de Vries  
>
> * configure.ac: Add --without-makeinfo.
> * configure: Regenerate.
>
> ---
>  configure| 4 
>  configure.ac | 4 
>  2 files changed, 8 insertions(+)
>
> diff --git a/configure b/configure
> index f14e0efd675..eb84add60cb 100755
> --- a/configure
> +++ b/configure
> @@ -8399,6 +8399,9 @@ fi
>  done
>  test -n "$MAKEINFO" || MAKEINFO="$MISSING makeinfo"
>
> +if test $with_makeinfo = "no"; then
> +MAKEINFO=true
> +else
>  case " $build_configdirs " in
>*" texinfo "*) MAKEINFO='$$r/$(BUILD_SUBDIR)/texinfo/makeinfo/makeinfo' ;;
>*)
> @@ -8414,6 +8417,7 @@ case " $build_configdirs " in
>  ;;
>
>  esac
> +fi
>
>  # FIXME: expect and dejagnu may become build tools?
>
> diff --git a/configure.ac b/configure.ac
> index 0152c69292e..e4a2c076674 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -3441,6 +3441,9 @@ case " $build_configdirs " in
>  esac
>
>  AC_CHECK_PROGS([MAKEINFO], makeinfo, [$MISSING makeinfo])

A new configure flag starting with the "--with-" prefix should use the
AC_ARG_WITH autoconf macro, along with the AS_HELP_STRING macro so
that it shows up in `./configure --help`. Check other places where
AC_ARG_WITH is used in configure.ac to see how it's done. Also, the
new option should be documented in install.texi as well.

> +if test $with_makeinfo = "no"; then
> +MAKEINFO=true
> +else
>  case " $build_configdirs " in
>*" texinfo "*) MAKEINFO='$$r/$(BUILD_SUBDIR)/texinfo/makeinfo/makeinfo' ;;
>*)
> @@ -3456,6 +3459,7 @@ changequote(,)
>  ;;
>  changequote([,])
>  esac
> +fi
>
>  # FIXME: expect and dejagnu may become build tools?
>

Re: [PATCH] configure: respect --with-build-time-tools [PR43301]

[Eric Gallager via Gcc-patches]

On Tue, Aug 2, 2022 at 11:33 PM Alexandre Oliva  wrote:
>
> On Aug  2, 2022, Eric Gallager  wrote:
>
> > On Tue, Aug 2, 2022 at 1:24 AM Alexandre Oliva  wrote:
>
> >> -elif test -x as$build_exeext; then
> >> +elif test -x as$build_exeext \
> >> +   && { test "x$build_exeext" != "x" \
> >> +|| test "x`grep '^# Invoke as, ld or nm from the build tree' \
> >> + as`" = "x"; }; then
> >>
> >> WDYT?
>
> > Hi, thanks for the feedback; I'm a bit confused, though: where exactly
> > would this proposed change go?
>
> gcc/configure.ac, just before:
>
> # Build using assembler in the current directory.
> gcc_cv_as=./as$build_exeext
>

OK, after reviewing the surrounding code, I think it makes sense; do
you want to commit it, or should I?
Thanks,
Eric

> --
> 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] configure: respect --with-build-time-tools [PR43301]

[Eric Gallager via Gcc-patches]

On Tue, Aug 2, 2022 at 1:24 AM Alexandre Oliva  wrote:
>
> Hello, Eric,
>
> Thanks for looking into this.
>
> On Aug  1, 2022, Eric Gallager via Gcc-patches  
> wrote:
>
> >> This just reassigns the value that was retrieved a couple of lines
> >> above from the very same variable.
>
> > Oh, ok, so I guess this isn't necessary after all?
>
> Yeah, I don't see how this patch could make any difference as to the
> reported problem.
>
> > In which case we can just close 43301 as INVALID then?
>
> AFAICT, with_build_time_tools is dealt with in the top level configure,
> setting up *_FOR_TARGET after searching for the tool names in the
> specified location.
>
> However, there's a potentially confusing consequence of the current
> code: gcc/configure looks for ./as$build_exeext in the build tree, and
> uses that without overwriting it if found, so if an earlier configure
> run created an 'as' script, a reconfigure will just use it, without
> creating the file again, even if it would have changed
> ORIGINAL_AS_FOR_TARGET in it.
>
> I suppose if the patch was tested by the original submitter on a clean
> build tree, so it would *appear* to have made a difference in fixing the
> problem, while it was actually just a no-op, and the apparent fix was a
> consequence of the clean build tree.
>
> So, the patch is not useful, but we may want to avoid the confusing
> scenario somehow.
>
> I suppose the point of not creating such a tiny script again is not to
> avoid unnecessary rebuilding of dependencies (I don't even see how
> dependencies on the script would come into play), so creating it again
> wouldn't hurt.  However, we wish to avoid overwriting an assembler
> copied into the build tree for use by gcc during the build.  Perhaps:
>
> -elif test -x as$build_exeext; then
> +elif test -x as$build_exeext \
> +   && { test "x$build_exeext" != "x" \
> +|| test "x`grep '^# Invoke as, ld or nm from the build tree' \
> + as`" = "x"; }; then
>
> WDYT?

Hi, thanks for the feedback; I'm a bit confused, though: where exactly
would this proposed change go?

>
> --
> 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 <https://stallmansupport.org>

Re: [PATCH] configure: respect --with-build-time-tools [PR43301]

[Eric Gallager via Gcc-patches]

On Mon, Aug 1, 2022 at 3:54 AM Andreas Schwab  wrote:
>
> On Jul 31 2022, Eric Gallager via Gcc-patches wrote:
>
> > It just makes the configure script respect the --with-build-time-tools
> > flag.
>
> Why does it make any difference?
>

See the original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43301

> > diff --git a/configure b/configure
> > index 65d7078dbe7..4d46b94ebc4 100755
> > --- a/configure
> > +++ b/configure
> > @@ -12850,7 +12850,9 @@ fi
> >  # Check whether --with-build-time-tools was given.
> >  if test "${with_build_time_tools+set}" = set; then :
> >withval=$with_build_time_tools; case x"$withval" in
> > - x/*) ;;
> > + x/*)
> > +   with_build_time_tools=$withval
>
> This just reassigns the value that was retrieved a couple of lines
> above from the very same variable.
>

Oh, ok, so I guess this isn't necessary after all? In which case we
can just close 43301 as INVALID then?

> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."

[PATCH] configure: respect --with-build-time-tools [PR43301]

[Eric Gallager via Gcc-patches]

Hi, there's been a patch sitting in bug 43301 for over a decade that I
think still makes sense to apply, so I rebased it against current
trunk and found that it still applies. It just makes the configure
script respect the --with-build-time-tools flag. OK to commit?

ChangeLog:

PR bootstrap/43301
* configure: Regenerate.
* configure.ac: Respect --with-build-time-tools flag.


patch-configure_1.diff
Description: Binary data

Re: [PATCH v2 1/7] config: use $EGREP instead of egrep

[Eric Gallager via Gcc-patches]

On Mon, Jun 27, 2022 at 2:07 AM Xi Ruoyao via Gcc-patches
 wrote:
>
> egrep has been deprecated in favor of grep -E for a long time, and the
> next GNU grep release (3.8 or 4.0) will print a warning if egrep is used.
> Unfortunately, old hosts with non-GNU grep may lack the support for -E
> option.  Use AC_PROG_EGREP and $EGREP variable so we'll work fine on
> both old and new platforms.
>
> ChangeLog:
>
> * configure.ac: Call AC_PROG_EGREP, and use $EGREP instead of
> egrep.
> * config.rpath: Use $EGREP instead of egrep.

config.rpath is imported from gnulib where this problem is already
fixed apparently; wouldn't it make more sense to re-import a fresh
config.rpath from upstream gnulib instead of patching GCC's local
copy?


> * configure: Regenerate.
>
> config/ChangeLog:
>
> * lib-ld.m4 (AC_LIB_PROG_LD_GNU): Call AC_PROG_EGREP, and use
> $EGREP instead of egrep.
> (acl_cv_path_LD): Likewise.
> * lib-link.m4 (AC_LIB_RPATH): Call AC_PROG_EGREP, and pass
> $EGREP to config.rpath.
>
> gcc/ChangeLog:
>
> * configure: Regenerate.
>
> intl/ChangeLog:
>
> * configure: Regenerate.
>
> libcpp/ChangeLog:
>
> * configure: Regenerate.
>
> libgcc/ChangeLog:
>
> * configure: Regenerate.
>
> libstdc++-v3/ChangeLog:
>
> * configure: Regenerate.
> ---
>  config.rpath   |  10 +--
>  config/lib-ld.m4   |   6 +-
>  config/lib-link.m4 |   4 +-
>  configure  | 136 -
>  configure.ac   |   5 +-
>  gcc/configure  |  13 ++--
>  intl/configure |   9 +--
>  libcpp/configure   |   9 +--
>  libgcc/configure   |   2 +-
>  libstdc++-v3/configure |   9 +--
>  10 files changed, 172 insertions(+), 31 deletions(-)
>
> diff --git a/config.rpath b/config.rpath
> index 4dea75957c2..4ada7468c22 100755
> --- a/config.rpath
> +++ b/config.rpath
> @@ -29,7 +29,7 @@
>  #CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM
>  # or
>  #CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM
> -# The environment variables CC, GCC, LDFLAGS, LD, with_gnu_ld
> +# The environment variables CC, GCC, EGREP, LDFLAGS, LD, with_gnu_ld
>  # should be set by the caller.
>  #
>  # The set of defined variables is at the end of this script.
> @@ -143,7 +143,7 @@ if test "$with_gnu_ld" = yes; then
>ld_shlibs=no
>;;
>  beos*)
> -  if $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; 
> then
> +  if $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > /dev/null; 
> then
>  :
>else
>  ld_shlibs=no
> @@ -162,9 +162,9 @@ if test "$with_gnu_ld" = yes; then
>  netbsd*)
>;;
>  solaris* | sysv5*)
> -  if $LD -v 2>&1 | egrep 'BFD 2\.8' > /dev/null; then
> +  if $LD -v 2>&1 | $EGREP 'BFD 2\.8' > /dev/null; then
>  ld_shlibs=no
> -  elif $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; 
> then
> +  elif $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > 
> /dev/null; then
>  :
>else
>  ld_shlibs=no
> @@ -174,7 +174,7 @@ if test "$with_gnu_ld" = yes; then
>hardcode_direct=yes
>;;
>  *)
> -  if $LD --help 2>&1 | egrep ': supported targets:.* elf' > /dev/null; 
> then
> +  if $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > /dev/null; 
> then
>  :
>else
>  ld_shlibs=no
> diff --git a/config/lib-ld.m4 b/config/lib-ld.m4
> index 11d0ce77342..88a014b7a74 100644
> --- a/config/lib-ld.m4
> +++ b/config/lib-ld.m4
> @@ -14,7 +14,8 @@ dnl From libtool-1.4. Sets the variable with_gnu_ld to yes 
> or no.
>  AC_DEFUN([AC_LIB_PROG_LD_GNU],
>  [AC_CACHE_CHECK([if the linker ($LD) is GNU ld], acl_cv_prog_gnu_ld,
>  [# I'd rather use --version here, but apparently some GNU ld's only accept 
> -v.
> -if $LD -v 2>&1 &5; then
> +AC_REQUIRE([AC_PROG_EGREP])dnl
> +if $LD -v 2>&1 &5; then
>acl_cv_prog_gnu_ld=yes
>  else
>acl_cv_prog_gnu_ld=no
> @@ -28,6 +29,7 @@ AC_DEFUN([AC_LIB_PROG_LD],
>  [  --with-gnu-ld   assume the C compiler uses GNU ld [default=no]],
>  test "$withval" = no || with_gnu_ld=yes, with_gnu_ld=no)
>  AC_REQUIRE([AC_PROG_CC])dnl
> +AC_REQUIRE([AC_PROG_EGREP])dnl
>  AC_REQUIRE([AC_CANONICAL_HOST])dnl
>  # Prepare PATH_SEPARATOR.
>  # The user is always right.
> @@ -88,7 +90,7 @@ AC_CACHE_VAL(acl_cv_path_LD,
># Check to see if the program is GNU ld.  I'd rather use --version,
># but apparently some GNU ld's only accept -v.
># Break only if it was the GNU/non-GNU ld that we prefer.
> -  if "$acl_cv_path_LD" -v 2>&1 < /dev/null | egrep '(GNU|with BFD)' > 
> /dev/null; then
> +  if "$acl_cv_path_LD" -v 2>&1 < /dev/null | $EGREP '(GNU|with BFD)' > 
> /dev/null; then
> test "$with_gnu_ld" != no && break
>else
> test "$with_gnu_ld" != yes && break
> diff --git a/config/lib-link.m4 b/config/lib-link.m4
> index 

Re: [PATCH v2 2/7] fixincludes: use grep instead of egrep/fgrep

[Eric Gallager via Gcc-patches]

On Mon, Jun 27, 2022 at 2:10 AM Xi Ruoyao via Gcc-patches
 wrote:
>
> egrep/fgrep has been deprecated in favor of grep -E/-F for a long time,
> and the next grep release (3.8 or 4.0) will print a warning if egrep or
> fgrep is used.  Stop using egrep and fgrep so we won't see the warning.
>
> But, we can't simply replace egrep to grep -E or fgrep to grep -F or the
> build will break with some non-GNU grep implementations (lacking -E or
> -F support).  autoconf documentation suggests to use AC_PROG_EGREP and
> $EGREP or AC_PROG_FGREP and FGREP, but doing so is too complicated for
> fixincludes.
>
> So we simply adjust the patterns for a plain grep, instead of relying on
> the behavior of grep -E/-F.
>
> Q: Why "[ \t][ \t]*" instead of "[ \t]\\+"?
> A: POSIX does not allow escaping + in BRE.
>
> fixincludes/ChangeLog:
>
> * fixinc.in: Use grep instead of egrep.
> * inclhack.def: Use grep instead of egrep, and adjust an
> regular expression to make it a BRE.
> * genfixes: Use grep instead of egrep, and escape "." in the
> pattern.
> * fixincl.x: Regenerate.
> ---
>  fixincludes/fixinc.in|  2 +-
>  fixincludes/fixincl.x| 10 +-
>  fixincludes/genfixes |  2 +-
>  fixincludes/inclhack.def |  6 +++---
>  4 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
> index 0bd8027a554..a4cd3d0fbb4 100755
> --- a/fixincludes/fixinc.in
> +++ b/fixincludes/fixinc.in
> @@ -448,7 +448,7 @@ while [ $# != 0 ]; do
>  chmod a+r $3 2>/dev/null
>  if test $VERBOSE -gt 2
>  then echo Copied $2 ; fi
> -for include in `egrep '^[  ]*#[]*include[  ]*"[^/]' $3 |
> +for include in `grep '^[   ]*#[]*include[  ]*"[^/]' $3 |
>   sed -e 's/^[  ]*#[]*include[  ]*"\([^"]*\)".*$/\1/'`
>  do
>   dir=`echo $2 | sed -e s'|/[^/]*$||'`
> diff --git a/fixincludes/fixincl.x b/fixincludes/fixincl.x
> index bad490453b7..c9b4cf504f2 100644
> --- a/fixincludes/fixincl.x
> +++ b/fixincludes/fixincl.x
> @@ -2,11 +2,11 @@
>   *
>   * DO NOT EDIT THIS FILE   (fixincl.x)
>   *
> - * It has been AutoGen-ed  February 27, 2022 at 07:47:03 PM by AutoGen 
> 5.18.16
> + * It has been AutoGen-ed  June 25, 2022 at 12:44:14 PM by AutoGen 5.18.16
>   * From the definitionsinclhack.def
>   * and the template file   fixincl
>   */
> -/* DO NOT SVN-MERGE THIS FILE, EITHER Sun Feb 27 19:47:03 UTC 2022
> +/* DO NOT SVN-MERGE THIS FILE, EITHER Sat Jun 25 12:44:14 CST 2022

So, this is kind of a tangent, but since GCC has migrated from SVN to
git, perhaps it's time to update this comment?

>   *
>   * You must regenerate it.  Use the ./genfixes script.
>   *
> @@ -6547,7 +6547,7 @@ static tTestDesc aMath_Huge_Val_From_Dbl_MaxTests[] = {
>   *  Fix Command Arguments for Math_Huge_Val_From_Dbl_Max
>   */
>  static const char* apzMath_Huge_Val_From_Dbl_MaxPatch[] = { "sh", "-c",
> -"\tdbl_max_def=`egrep 'define[ \t]+DBL_MAX[ \t]+.*' float.h | sed 
> 's/.*DBL_MAX[ \t]*//' 2>/dev/null`\n\n\
> +"\tdbl_max_def=`grep 'define[ \t][ \t]*DBL_MAX[ \t][ \t]*.*' float.h | 
> sed 's/.*DBL_MAX[ \t]*//' 2>/dev/null`\n\n\
>  \tif ( test -n \"${dbl_max_def}\" ) > /dev/null 2>&1\n\
>  \tthen sed -e '/define[ \t]*HUGE_VAL[ 
> \t]*DBL_MAX/s@DBL_MAX@'\"$dbl_max_def@\"\n\
>  \telse cat\n\
> @@ -10402,9 +10402,9 @@ tSCC zVxworks_Needs_VxworksSelect0[] =
>  tSCC zVxworks_Needs_VxworksTest0[] =
> " -r types/vxTypesOld.h";
>  tSCC zVxworks_Needs_VxworksTest1[] =
> -   " -n \"`egrep '#include' $file`\"";
> +   " -n \"`grep '#include' $file`\"";
>  tSCC zVxworks_Needs_VxworksTest2[] =
> -   " -n \"`egrep ULONG $file`\"";
> +   " -n \"`grep ULONG $file`\"";
>
>  #defineVXWORKS_NEEDS_VXWORKS_TEST_CT  4
>  static tTestDesc aVxworks_Needs_VxworksTests[] = {
> diff --git a/fixincludes/genfixes b/fixincludes/genfixes
> index 47aad01289d..3a4c05c832b 100755
> --- a/fixincludes/genfixes
> +++ b/fixincludes/genfixes
> @@ -58,7 +58,7 @@ done
>  AG="autogen $AG"
>  set -e
>
> -if [ -z "`${AG} -v | fgrep ' 5.'`" ]
> +if [ -z "`${AG} -v | grep ' 5\.'`" ]
>  then
>echo "AutoGen appears to be out of date or not correctly installed."
>echo "Please download and install from:"
> diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
> index 7605ac89aa2..080bbc010dc 100644
> --- a/fixincludes/inclhack.def
> +++ b/fixincludes/inclhack.def
> @@ -3274,7 +3274,7 @@ fix = {
>   *  If we do, we will replace the one in math.h with that one.
>   */
>
> -"\tdbl_max_def=`egrep 'define[ \t]+DBL_MAX[ \t]+.*' float.h "
> +"\tdbl_max_def=`grep 'define[ \t][ \t]*DBL_MAX[ \t][ \t]*.*' float.h "
> "| sed 's/.*DBL_MAX[ \t]*//' 2>/dev/null`\n\n"
>
>  "\tif ( test -n \"${dbl_max_def}\" ) > /dev/null 2>&1\n"
> @@ -5266,8 +5266,8 @@ fix = {
>  hackname = vxworks_needs_vxworks;
>  files= sys/stat.h;
>  test   

Re: [PATCH] gcc/configure.ac: fix --enable-fixed-point enablement [PR34422]

[Eric Gallager via Gcc-patches]

Hi, I'd like to ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596654.html
(cc-ing the build machinery maintainers listed in MAINTAINERS this time)

On Tue, Jun 14, 2022 at 3:51 PM Eric Gallager  wrote:
>
> So, in investigating PR target/34422, I discovered that the gcc
> subdirectory's configure script had an instance of AC_ARG_ENABLE with
> 3rd and 4th its arguments reversed: the one where it warns that the
> --enable-fixed-point flag is being ignored is the one where that flag
> hasn't even been passed in the first place. The attached patch puts
> the warning in the correct argument to the macro in question. (I'm not
> including the regeneration of gcc/configure in the patch this time
> since that confused people last time.) OK to commit, with an
> appropriate ChangeLog?

Re: [PATCH] c: Extend the -Wpadded message with actual padding size

[Eric Gallager via Gcc-patches]

On Thu, Jun 16, 2022 at 3:37 PM Vit Kabele  wrote:
>
> When the compiler warns about padding struct to alignment boundary, it
> now also informs the user about the size of the alignment that needs to
> be added to get rid of the warning.

Hi, thanks for taking the time to improve -Wpadded; I have been
wishing that GCC's implementation of -Wpadded would print this
information for a while now and thought there was a bug open for it,
but can't seem to find it now...

>
> This removes the need of using pahole or similar tools, or manually
> determining the padding size.
>
> Tested on x86_64-pc-linux-gnu.
>
> gcc/ChangeLog:
>
> * stor-layout.cc (finalize_record_size): Improve warning message
>
> Signed-off-by: Vit Kabele 
> ---
>  gcc/stor-layout.cc | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/stor-layout.cc b/gcc/stor-layout.cc
> index 765f22f68b9..57ddb001780 100644
> --- a/gcc/stor-layout.cc
> +++ b/gcc/stor-layout.cc
> @@ -1781,7 +1781,14 @@ finalize_record_size (record_layout_info rli)
>&& simple_cst_equal (unpadded_size, TYPE_SIZE (rli->t)) == 0
>&& input_location != BUILTINS_LOCATION
>&& !TYPE_ARTIFICIAL (rli->t))
> -warning (OPT_Wpadded, "padding struct size to alignment boundary");
> +  {
> +  tree padding_size
> +   = size_binop (MINUS_EXPR,
> +   TYPE_SIZE_UNIT (rli->t), unpadded_size_unit);
> +  warning (OPT_Wpadded,
> +  "padding struct size to alignment boundary with %E bytes",
> +  padding_size);
> +  }

Style nit: indentation seems off; check your tabs vs. spaces etc.

>
>if (warn_packed && TREE_CODE (rli->t) == RECORD_TYPE
>&& TYPE_PACKED (rli->t) && ! rli->packed_maybe_necessary
> --
> 2.30.2

[PATCH] gcc/configure.ac: fix --enable-fixed-point enablement [PR34422]

[Eric Gallager via Gcc-patches]

So, in investigating PR target/34422, I discovered that the gcc
subdirectory's configure script had an instance of AC_ARG_ENABLE with
3rd and 4th its arguments reversed: the one where it warns that the
--enable-fixed-point flag is being ignored is the one where that flag
hasn't even been passed in the first place. The attached patch puts
the warning in the correct argument to the macro in question. (I'm not
including the regeneration of gcc/configure in the patch this time
since that confused people last time.) OK to commit, with an
appropriate ChangeLog?


patch-gcc_configure.diff
Description: Binary data

Re: [PATCH][WIP] have configure probe prefix for gmp/mpfr/mpc [PR44425]

[Eric Gallager via Gcc-patches]

On Mon, Jun 13, 2022 at 7:02 AM Richard Biener
 wrote:
>
> On Thu, Jun 2, 2022 at 5:54 PM Eric Gallager via Gcc-patches
>  wrote:
> >
> > So, I'm working on fixing PR bootstrap/44425, and have this patch to
> > have the top-level configure script check in the value passed to
> > `--prefix=` when looking for gmp/mpfr/mpc. It "works" (in that
> > configuring with just `--prefix=` and none of
> > `--with-gmp=`/`--with-mpfr=`/`--with-mpc=` now works where it failed
> > before), but unfortunately it results in a bunch of duplicated
> > `-I`/`-L` flags stuck in ${gmplibs} and ${gmpinc}... is that
> > acceptable or should I try another approach?
>
> --prefix is documented as to be used for installing (architecture
> independent) files,
> I'm not sure it is a good idea to probe that for gmp/mpfr/mpc installs used 
> for
> the host.
>
> Richard.
>
> > Eric

So... I guess that means we should close bug 44425 as INVALID or
WONTFIX then? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44425

Re: [PING][PATCH][WIP] have configure probe prefix for gmp/mpfr/mpc [PR44425]

[Eric Gallager via Gcc-patches]

On Fri, Jun 10, 2022 at 7:22 AM Xi Ruoyao  wrote:
>
> On Thu, 2022-06-09 at 16:04 -0400, Eric Gallager via Gcc-patches wrote:
> > Hi, I'd like to ping this patch:
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596126.html
> > (cc-ing the build machinery maintainers listed in MAINTAINERS this
> > time)
> >
> > On Thu, Jun 2, 2022 at 11:53 AM Eric Gallager 
> > wrote:
> > >
> > > So, I'm working on fixing PR bootstrap/44425, and have this patch to
> > > have the top-level configure script check in the value passed to
> > > `--prefix=` when looking for gmp/mpfr/mpc. It "works" (in that
> > > configuring with just `--prefix=` and none of
> > > `--with-gmp=`/`--with-mpfr=`/`--with-mpc=` now works where it failed
> > > before), but unfortunately it results in a bunch of duplicated
> > > `-I`/`-L` flags stuck in ${gmplibs} and ${gmpinc}... is that
> > > acceptable or should I try another approach?
> > > Eric
>
> A patch should not edit configure directly.  configure.ac should be
> edited and configure should be regenerated from it.
>

That is precisely what the patch does: it edits configure.ac and
regenerates configure from it.

> --
> Xi Ruoyao 
> School of Aerospace Science and Technology, Xidian University

[PING][PATCH][WIP] have configure probe prefix for gmp/mpfr/mpc [PR44425]

[Eric Gallager via Gcc-patches]

Hi, I'd like to ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596126.html
(cc-ing the build machinery maintainers listed in MAINTAINERS this time)

On Thu, Jun 2, 2022 at 11:53 AM Eric Gallager  wrote:
>
> So, I'm working on fixing PR bootstrap/44425, and have this patch to
> have the top-level configure script check in the value passed to
> `--prefix=` when looking for gmp/mpfr/mpc. It "works" (in that
> configuring with just `--prefix=` and none of
> `--with-gmp=`/`--with-mpfr=`/`--with-mpc=` now works where it failed
> before), but unfortunately it results in a bunch of duplicated
> `-I`/`-L` flags stuck in ${gmplibs} and ${gmpinc}... is that
> acceptable or should I try another approach?
> Eric


patch-configure.diff
Description: Binary data

[PATCH][WIP] have configure probe prefix for gmp/mpfr/mpc [PR44425]

[Eric Gallager via Gcc-patches]

So, I'm working on fixing PR bootstrap/44425, and have this patch to
have the top-level configure script check in the value passed to
`--prefix=` when looking for gmp/mpfr/mpc. It "works" (in that
configuring with just `--prefix=` and none of
`--with-gmp=`/`--with-mpfr=`/`--with-mpc=` now works where it failed
before), but unfortunately it results in a bunch of duplicated
`-I`/`-L` flags stuck in ${gmplibs} and ${gmpinc}... is that
acceptable or should I try another approach?
Eric


patch-configure.diff
Description: Binary data

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.

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
>

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

[Eric Gallager via Gcc-patches]

On Fri, May 27, 2022 at 3:17 AM Simon Sobisch via Gcc-patches
 wrote:
>
> Hi fellow hackers,
>
> first of all: I'm not sure if this is the correct mailing list for this
> question, but I did not found a separate one and
> gnu.org/software/libiberty redirects to
> https://gcc.gnu.org/onlinedocs/libiberty.pdf - so I'm here.
> If there's a better place for this: please drop a note.
>
> I've never "worked" with libiberty directly but am sure I'm using it
> quite regularly with various tools including GDB and valgrind.
> Therefore I currently cannot send a patch for the function name
> demangling, but if this is a reasonable thing to add I'd like to work on
> this with someone.
>
> As noted: 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.

> A second question would be: Is there anyone who would be willing to work
> on this with me?
> Where would "we" or I start?
>
> Thank you for taking the time to read and possibly answer,
> Simon Sobisch
>
> Maintainer GnuCOBOL
>
>

Re: [PATCH 00/10] Add 'final' and 'override' where missing

[Eric Gallager via Gcc-patches]

On Mon, May 23, 2022 at 3:32 PM David Malcolm via Gcc-patches
 wrote:
>
> With C++11 we can add "final" and "override" to the decls of vfuncs
> in derived classes, which documents to both human and automated readers
> of the code that a decl is intended to override a vfunc in a base class,
> and can help catch mistakes where we intended to override a vfunc, but
> messed up the prototypes.
>
> The following patch kit adds "final" and "override" specifiers to the
> decls of vfunc implementations throughout the source tree.
>
> I added "final override" everywhere where this was possible, or just
> "override" for the places where the overridden vfunc gets further
> overridden.
>
> I also removed "virtual" from such decls, since this isn't required
> when overriding an existing vfunc, and the "final override" better
> implies the intent of the code.
>
> I temporarily hacked -Werror=suggest-override into the Makefile whilst
> I was creating the patches, but I skipped the following:
>
> (a) gcc/d/dmd/ ...since these sources are copied from an upstream
> (b) gcc/go/gofrontend/ ...likewise
> (c) gcc/range.op.cc: as I believe this code is under heavy development
> (d) target-specific passes other than i386 (for ease of testing); I can
> do these in a followup, if desired.
>
> I didn't attempt to add -Wsuggest-override into our compile flags
> "properly".

Have you tried clang's -Winconsistent-missing-override flag for
comparison? I noticed some warnings from it when doing a build of gcc
trunk with clang just now.

>
> No functional changes intended.
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
>
> I split them up into separate patches by topic for ease of review, and
> for ease of writing the ChangeLog entries.
>
> Worth an update to https://gcc.gnu.org/codingconventions.html ?
>
> OK for trunk?
> Dave
>
> David Malcolm (10):
>   Add 'final' and 'override' to opt_pass vfunc impls
>   Add 'final' and 'override' on dom_walker vfunc impls
>   expr.cc: use final/override on op_by_pieces_d vfuncs
>   tree-switch-conversion.h: use final/override for cluster vfunc impls
>   d: add 'final' and 'override' to gcc/d/*.cc 'visit' impls
>   ipa: add 'final' and 'override' to call_summary_base vfunc impls
>   value-relation.h: add 'final' and 'override' to relation_oracle vfunc
> impls
>   i386: add 'final' and 'override' to scalar_chain vfunc impls
>   tree-vect-slp-patterns.cc: add 'final' and 'override' to
> vect_pattern::build impls
>   Add 'final' and 'override' in various places
>
>  gcc/adjust-alignment.cc  |  2 +-
>  gcc/asan.cc  | 19 ++---
>  gcc/auto-inc-dec.cc  |  4 +-
>  gcc/auto-profile.cc  |  8 ++--
>  gcc/bb-reorder.cc| 12 +++---
>  gcc/cfgcleanup.cc|  8 ++--
>  gcc/cfgexpand.cc |  2 +-
>  gcc/cfgrtl.cc|  6 +--
>  gcc/cgraphbuild.cc   | 13 +++---
>  gcc/combine-stack-adj.cc |  4 +-
>  gcc/combine.cc   |  4 +-
>  gcc/compare-elim.cc  |  6 +--
>  gcc/config/i386/i386-features.cc | 20 -
>  gcc/config/i386/i386-features.h  | 16 +++
>  gcc/coroutine-passes.cc  |  8 ++--
>  gcc/cp/cxx-pretty-print.h| 38 -
>  gcc/cp/module.cc |  4 +-
>  gcc/cprop.cc |  9 ++--
>  gcc/cse.cc   | 18 +---
>  gcc/d/decl.cc| 36 
>  gcc/d/expr.cc|  2 +-
>  gcc/d/toir.cc| 64 ++--
>  gcc/d/typeinfo.cc| 34 +++
>  gcc/d/types.cc   | 30 ++---
>  gcc/dce.cc   |  8 ++--
>  gcc/df-core.cc   | 10 ++---
>  gcc/dse.cc   | 14 --
>  gcc/dwarf2cfi.cc |  7 ++-
>  gcc/early-remat.cc   |  4 +-
>  gcc/except.cc|  6 +--
>  gcc/expr.cc  | 14 +++---
>  gcc/final.cc | 14 --
>  gcc/function.cc  | 10 ++---
>  gcc/fwprop.cc|  8 ++--
>  gcc/gcse.cc  | 14 --
>  gcc/genmatch.cc  | 22 +-
>  gcc/gensupport.cc|  2 +-
>  gcc/gimple-harden-conditionals.cc| 20 ++---
>  gcc/gimple-if-to-switch.cc   |  4 +-
>  gcc/gimple-isel.cc   |  4 +-
>  gcc/gimple-laddress.cc   |  6 +--
>  gcc/gimple-loop-interchange.cc   |  6 +--
>  gcc/gimple-loop-jam.cc   |  4 +-
>  gcc/gimple-loop-versioning.cc|  7 ++-
>  gcc/gimple-low.cc|  5 ++-
>  gcc/gimple-range-cache.h |  4 +-
>  gcc/gimple-ssa-backprop.cc   |  6 +--
>  gcc/gimple-ssa-evrp.cc  

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

[Eric Gallager via Gcc-patches]

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


patch-sourcebuild.texi.diff
Description: Binary data

Re: [PATCH] configure: cache result of "sys/sdt.h" header check

[Eric Gallager via Gcc-patches]

On Thu, Mar 24, 2022 at 9:27 AM David Seifert via Gcc-patches
 wrote:
>
> On Mon, 2022-03-14 at 18:38 +0100, David Seifert wrote:
> > Use AC_CACHE_CHECK to store the result of the header check for
> > systemtap's "sys/sdt.h", which is similar in spirit to libstdc++'s
> > AC_CACHE_CHECK(..., glibcxx_cv_sys_sdt_h).
> >
> > gcc/
> > * configure.ac: Add AC_CACHE_CHECK(..., gcc_cv_sys_sdt_h).
> > * configure: Regenerate.
> > ---
> >  gcc/configure| 20 +++-
> >  gcc/configure.ac | 16 +---
> >  2 files changed, 24 insertions(+), 12 deletions(-)
> >
> > diff --git a/gcc/configure b/gcc/configure
> > index 14b19c8fe0c..1dfc5cc7344 100755
> > --- a/gcc/configure
> > +++ b/gcc/configure
> > @@ -31389,15 +31389,25 @@ fi
> >
> >  { $as_echo "$as_me:${as_lineno-$LINENO}: checking sys/sdt.h in the
> > target C library" >&5
> >  $as_echo_n "checking sys/sdt.h in the target C library... " >&6; }
> > -have_sys_sdt_h=no
> > -if test -f $target_header_dir/sys/sdt.h; then
> > -  have_sys_sdt_h=yes
> > +if ${gcc_cv_sys_sdt_h+:} false; then :
> > +  $as_echo_n "(cached) " >&6
> > +else
> > +
> > +  gcc_cv_sys_sdt_h=no
> > +  if test -f $target_header_dir/sys/sdt.h; then
> > +gcc_cv_sys_sdt_h=yes
> > +  fi
> > +
> > +fi
> > +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_sys_sdt_h"
> > >&5
> > +$as_echo "$gcc_cv_sys_sdt_h" >&6; }
> > +if test x$gcc_cv_sys_sdt_h = xyes; then :
> > +
> >
> >  $as_echo "#define HAVE_SYS_SDT_H 1" >>confdefs.h
> >
> > +
> >  fi
> > -{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $have_sys_sdt_h" >&5
> > -$as_echo "$have_sys_sdt_h" >&6; }
> >
> >  # Check if TFmode long double should be used by default or not.
> >  # Some glibc targets used DFmode long double, but with glibc 2.4
> > diff --git a/gcc/configure.ac b/gcc/configure.ac
> > index 90cad309762..c86ce5e0a9b 100644
> > --- a/gcc/configure.ac
> > +++ b/gcc/configure.ac
> > @@ -6904,14 +6904,16 @@ AC_SUBST([enable_default_ssp])
> >
> >  # Test for  on the target.
> >  GCC_TARGET_TEMPLATE([HAVE_SYS_SDT_H])
> > -AC_MSG_CHECKING(sys/sdt.h in the target C library)
> > -have_sys_sdt_h=no
> > -if test -f $target_header_dir/sys/sdt.h; then
> > -  have_sys_sdt_h=yes
> > -  AC_DEFINE(HAVE_SYS_SDT_H, 1,
> > +AC_CACHE_CHECK([sys/sdt.h in the target C library],
> > [gcc_cv_sys_sdt_h], [
> > +  gcc_cv_sys_sdt_h=no
> > +  if test -f $target_header_dir/sys/sdt.h; then
> > +gcc_cv_sys_sdt_h=yes
> > +  fi
> > +])
> > +AS_IF([test x$gcc_cv_sys_sdt_h = xyes], [
> > +  AC_DEFINE([HAVE_SYS_SDT_H], [1],
> >  [Define if your target C library provides sys/sdt.h])
> > -fi
> > -AC_MSG_RESULT($have_sys_sdt_h)
> > +])
> >
> >  # Check if TFmode long double should be used by default or not.
> >  # Some glibc targets used DFmode long double, but with glibc 2.4
>
> Ping, I think we agreed making this a cache variable is fine (which is
> how libstdc++ also does it).
>

So wait does this supersede the one adding a configure flag for it?
i.e.: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591704.html

Re: [PATCH] gcc: add --enable-systemtap switch [PR61257]

[Eric Gallager via Gcc-patches]

On Mon, Mar 14, 2022 at 10:13 AM Jakub Jelinek via Gcc-patches
 wrote:
>
> On Mon, Mar 14, 2022 at 09:26:57AM -0400, Marek Polacek via Gcc-patches wrote:
> > Thanks for the patch.
> >
> > The new configure option needs documenting in doc/install.texi, and 
> > configure
> > needs to be regenerated.
>
> More importantly, I don't see explanation why the patch is needed,

The patch was requested in bug 61257:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61257

> analysis why did the HAVE_SYS_SDT_H configure check say that the header
> exists but trying to include it in libgcc doesn't.
>
> Jakub
>

Re: [PATCH][wwwdocs] Document ASAN changes for GCC 13.

[Eric Gallager via Gcc-patches]

On Tue, May 24, 2022 at 8:42 AM Martin Liška  wrote:
>
> Ready to be installed?
>
> Thanks,
> Martin
>
> ---
>  htdocs/gcc-13/changes.html | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
> index 6c5b2a37..f7f6866d 100644
> --- a/htdocs/gcc-13/changes.html
> +++ b/htdocs/gcc-13/changes.html
> @@ -47,6 +47,9 @@ a work-in-progress.
>  non-rectangular loop nests, which were added for C/C++ in GCC 11.
>
>
> +AddressSanitizer defaults to 
> detect_stack_use_after_return=1 on Linux target.
> +For compatibly, it can be disabled with env 
> ASAN_OPTIONS=detect_stack_use_after_return=0.
> +  
>  
>

Hm, the HTML tags look mismatched... also I'm assuming "compatibly"
should be "compatibility"?

>
> --
> 2.36.1
>

Re: [PATCH] Fold GCC_VERSION >= $old_version to TRUE, otherwise to FALSE.

[Eric Gallager via Gcc-patches]

On Thu, May 5, 2022 at 2:26 PM Martin Liška  wrote:
>
> On 5/5/22 14:24, Richard Biener wrote:
> > Hmm, but we support C++11 host compilers that are not GCC but
> > may claim to be, with GCC_VERSION 4.2.x for example.  Are we sure
> > all those liars implement what we guard with the version checks?
>
> Do you know about any real example of such a liars?
> Why should we even care about them?
>

Well, there's clang, for one (which pretends to be gcc 4.2), which is
kind of a big deal...

> Martin
>
> >
> > I suppose to be "correct" we'd at least need to preserve
> > #if __GNUC__
> > in places where we might use the host compiler?  (if compilers then lie
> > it's their own fault)
>

Re: [PATCH] Use more ARRAY_SIZE.

[Eric Gallager via Gcc-patches]

On Wed, May 11, 2022 at 9:53 AM David Malcolm via Gcc-patches
 wrote:
>
> On Thu, 2022-05-05 at 14:16 +0200, Martin Liška wrote:
> > Patch can bootstrap on x86_64-linux-gnu and survives regression
> > tests.
> >
> > Ready to be installed?
>
> I looked over the changes to:
>
>   gcc/analyzer/*.cc
>   gcc/input.cc
>   gcc/jit/*.cc
>
> and they look good to me.
>
> I assume that you enabled "jit" during the testing, right?  (it's not
> in --enable-languages=all, which is a perennial source of issues).
>

So, what remains to be done to include "jit" in "all" anyways? Are
there still some platforms left that it's not supported on yet or
something?

> Thanks
> Dave
>
>

Re: [PATCH] libiberty: stop using PTR macro.

[Eric Gallager via Gcc-patches]

On Tue, May 10, 2022 at 5:37 AM Martin Liška  wrote:
>
> Hi.
>
> As noticed by Alan, we can stop using the non-ANSI C specific macro (PTR).
> Let's removed its usafe in libiberty.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> include/ChangeLog:
>
> * hashtab.h (HTAB_EMPTY_ENTRY): Use void * instead PTR.
> (HTAB_DELETED_ENTRY): Likewise.
>
> libiberty/ChangeLog:
>
> * alloca.c (C_alloca): Use void * instead PTR.
> * calloc.c (malloc): Likewise.
> (bzero): Likewise.
> (calloc): Likewise.
> * hashtab.c (find_empty_slot_for_expand): Likewise.
> (eq_pointer): Likewise.
> (htab_create_alloc_ex): Likewise.
> (htab_create_typed_alloc): Likewise.
> (htab_set_functions_ex): Likewise.
> (htab_delete): Likewise.
> (htab_empty): Likewise.
> (htab_expand): Likewise.
> (htab_find_with_hash): Likewise.
> (htab_find): Likewise.
> (htab_find_slot_with_hash): Likewise.
> (htab_find_slot): Likewise.
> (htab_remove_elt): Likewise.
> (htab_remove_elt_with_hash): Likewise.
> (htab_clear_slot): Likewise.
> (htab_traverse_noresize): Likewise.
> (htab_traverse): Likewise.
> (htab_hash_string): Likewise.
> (iterative_hash): Likewise.
> (hash_pointer): Likewise.
> * memchr.c (memchr): Likewise.
> * memcmp.c (memcmp): Likewise.
> * memcpy.c (memcpy): Likewise.
> * memmove.c (memmove): Likewise.
> * mempcpy.c (memcpy): Likewise.
> (mempcpy): Likewise.
> * memset.c (memset): Likewise.
> * objalloc.c (malloc): Likewise.
> (free): Likewise.
> (objalloc_create): Likewise.
> (_objalloc_alloc): Likewise.
> (objalloc_free_block): Likewise.
> * random.c (PTR): Likewise.
> (void): Likewise.
> (initstate): Likewise.
> (setstate): Likewise.
> * regex.c: Likewise.
> * spaces.c (malloc): Likewise.
> (free): Likewise.
> * stpcpy.c (memcpy): Likewise.
> * strdup.c (malloc): Likewise.
> (memcpy): Likewise.
> * strerror.c (malloc): Likewise.
> (memset): Likewise.
> * strndup.c (malloc): Likewise.
> (memcpy): Likewise.
> * strsignal.c (malloc): Likewise.
> (memset): Likewise.
> * vasprintf.c (malloc): Likewise.
> * vprintf-support.c: Likewise.
> * xatexit.c (malloc): Likewise.
> * xmalloc.c (xmalloc): Likewise.
> (xcalloc): Likewise.
> (xrealloc): Likewise.
> * xmemdup.c (xmemdup): Likewise.
> ---
>  include/hashtab.h   |  4 +-
>  libiberty/alloca.c  |  7 ++-
>  libiberty/calloc.c  |  9 ++--
>  libiberty/hashtab.c | 92 ++---
>  libiberty/memchr.c  |  5 +-
>  libiberty/memcmp.c  |  2 +-
>  libiberty/memcpy.c  |  3 +-
>  libiberty/memmove.c |  3 +-
>  libiberty/mempcpy.c |  5 +-
>  libiberty/memset.c  |  3 +-
>  libiberty/objalloc.c| 23 +-
>  libiberty/random.c  | 14 +++---
>  libiberty/regex.c   |  8 ++--
>  libiberty/spaces.c  |  4 +-
>  libiberty/stpcpy.c  |  2 +-
>  libiberty/strdup.c  |  4 +-
>  libiberty/strerror.c|  4 +-
>  libiberty/strndup.c |  4 +-
>  libiberty/strsignal.c   |  4 +-
>  libiberty/vasprintf.c   |  2 +-
>  libiberty/vprintf-support.c |  2 +-
>  libiberty/xatexit.c |  2 +-
>  libiberty/xmalloc.c | 15 +++---
>  libiberty/xmemdup.c |  7 ++-
>  24 files changed, 106 insertions(+), 122 deletions(-)
>
> diff --git a/include/hashtab.h b/include/hashtab.h
> index 7117eee2afb..e74d2226e08 100644
> --- a/include/hashtab.h
> +++ b/include/hashtab.h
> @@ -79,12 +79,12 @@ typedef void (*htab_free_with_arg) (void *, void *);
>
>  /* This macro defines reserved value for empty table entry.  */
>
> -#define HTAB_EMPTY_ENTRY((PTR) 0)
> +#define HTAB_EMPTY_ENTRY((void *) 0)
>
>  /* This macro defines reserved value for table entry which contained
> a deleted element. */
>
> -#define HTAB_DELETED_ENTRY  ((PTR) 1)
> +#define HTAB_DELETED_ENTRY  ((void *) 1)
>
>  /* Hash tables are of the following type.  The structure
> (implementation) of this type is not needed for using the hash
> diff --git a/libiberty/alloca.c b/libiberty/alloca.c
> index 9b2e9cb12b6..46f920517e1 100644
> --- a/libiberty/alloca.c
> +++ b/libiberty/alloca.c
> @@ -158,8 +158,7 @@ static header *last_alloca_header = NULL;   /* -> last 
> alloca header.  */
>
>  /* @undocumented C_alloca */
>
> -PTR
> -C_alloca (size_t size)
> +void *C_alloca (size_t size)

Hi, please preserve existing style when possible when making this
replacement; ISTR there are some tools (like for generating
libiberty's 

Re: [committed] jit: further doc fixes

[Eric Gallager via Gcc-patches]

On Fri, Apr 1, 2022 at 9:28 AM David Malcolm via Gcc-patches
 wrote:
>
> Further jit doc fixes, which fix links to
> gcc_jit_function_type_get_param_type and gcc_jit_struct_get_field.
>
> I also regenerated libgccjit.texi (not included in the diff below).
>
> Tested with "make html" and with a bootstrap.

 Could you test with `make pdf` and `make dvi` too, to see if this fixes 102824?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824

> Committed to trunk as r12-7959-g1a172da8a3f362.
>
> gcc/jit/ChangeLog:
> * docs/topics/expressions.rst: Fix formatting.
> * docs/topics/types.rst: Likewise.
> * docs/_build/texinfo/libgccjit.texi: Regenerate
>
> Signed-off-by: David Malcolm 
> ---
>  gcc/jit/docs/topics/expressions.rst | 8 
>  gcc/jit/docs/topics/types.rst   | 6 +++---
>  2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/gcc/jit/docs/topics/expressions.rst 
> b/gcc/jit/docs/topics/expressions.rst
> index 9267b6d2ad6..d51264af73f 100644
> --- a/gcc/jit/docs/topics/expressions.rst
> +++ b/gcc/jit/docs/topics/expressions.rst
> @@ -24,7 +24,7 @@ Rvalues
>  ---
>  .. type:: gcc_jit_rvalue
>
> -A :c:type:`gcc_jit_rvalue *` is an expression that can be computed.
> +A :c:type:`gcc_jit_rvalue` is an expression that can be computed.
>
>  It can be simple, e.g.:
>
> @@ -602,7 +602,7 @@ Function calls
>gcc_jit_rvalue_set_bool_require_tail_call (gcc_jit_rvalue 
> *call,\
>   int 
> require_tail_call)
>
> -   Given an :c:type:`gcc_jit_rvalue *` for a call created through
> +   Given an :c:type:`gcc_jit_rvalue` for a call created through
> :c:func:`gcc_jit_context_new_call` or
> :c:func:`gcc_jit_context_new_call_through_ptr`, mark/clear the
> call as needing tail-call optimization.  The optimizer will
> @@ -721,8 +721,8 @@ where the rvalue is computed by reading from the storage 
> area.
>
>#ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_tls_model
>
> -.. function:: void
> -  gcc_jit_lvalue_set_link_section (gcc_jit_lvalue *lvalue,
> +.. function:: void\
> +  gcc_jit_lvalue_set_link_section (gcc_jit_lvalue *lvalue,\
> const char *section_name)
>
> Set the link section of a variable.
> diff --git a/gcc/jit/docs/topics/types.rst b/gcc/jit/docs/topics/types.rst
> index 9779ad26b6f..c2082c0ef3e 100644
> --- a/gcc/jit/docs/topics/types.rst
> +++ b/gcc/jit/docs/topics/types.rst
> @@ -192,7 +192,7 @@ A compound type analagous to a C `struct`.
>
>  A field within a :c:type:`gcc_jit_struct`.
>
> -You can model C `struct` types by creating :c:type:`gcc_jit_struct *` and
> +You can model C `struct` types by creating :c:type:`gcc_jit_struct` and
>  :c:type:`gcc_jit_field` instances, in either order:
>
>  * by creating the fields, then the structure.  For example, to model:
> @@ -375,7 +375,7 @@ Reflection API
>   Given a function type, return its number of parameters.
>
>  .. function::  gcc_jit_type *\
> -   gcc_jit_function_type_get_param_type (gcc_jit_function_type 
> *function_type,
> +   gcc_jit_function_type_get_param_type (gcc_jit_function_type 
> *function_type,\
>   size_t index)
>
>   Given a function type, return the type of the specified parameter.
> @@ -417,7 +417,7 @@ Reflection API
>   alignment qualifiers.
>
>  .. function::  gcc_jit_field *\
> -   gcc_jit_struct_get_field (gcc_jit_struct *struct_type,
> +   gcc_jit_struct_get_field (gcc_jit_struct *struct_type,\
>   size_t index)
>
>   Get a struct field by index.
> --
> 2.26.3
>

Re: [PATCH] c : Changed warning message for -Wstrict-prototypes [PR92209]

[Eric Gallager via Gcc-patches]

On Fri, Mar 11, 2022 at 3:55 PM Joseph Myers  wrote:
>
> On Fri, 11 Mar 2022, Krishna Narayanan via Gcc-patches wrote:
>
> > Hello,
> > The following is a patch for the PR92209,which gives a warning when
> > the function prototype does not specify its argument type.In this
> > patch there has been a change in the warning message displayed for
> > -Wstrict-prototypes to specify its argument types.I have also added
> > the testcase for it.
> > Regtested on x86_64,OK for commit? Please do review it.
>
> Why do you think your proposed wording is better than the existing
> wording?  I think the existing wording is accurate and the proposed
> wording is inaccurate - "must specify the argument types" is not an
> accurate description of any requirement in the C language, using "must" at
> all generally seems questionable in the wording of a warning message.
>
> Also, I don't think this change is anything to do with the PR you mention
> ("Imprecise column number for -Wstrict-prototypes"), so it's wrong to
> mention that PR number in the proposed commit message.
>

The proposed wording comes from one of the comments in the mentioned
PR; see Manu's reply in comment #1:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92209#c1

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

Re: [PATCH] Make `-Werror` optional in libatomic/libbacktrace/libgomp/libitm/libsanitizer

[Eric Gallager via Gcc-patches]

On Mon, Jan 17, 2022 at 3:05 PM David Seifert via Gcc-patches
 wrote:
>
> * `-Werror` can cause issues when a more recent version of GCC compiles
>   an older version:
>   - https://bugs.gentoo.org/229059
>   - https://bugs.gentoo.org/475350
>   - https://bugs.gentoo.org/667104
> ---
>  libatomic/configure.ac| 6 --
>  libbacktrace/configure.ac | 7 ---
>  libgomp/configure.ac  | 6 --
>  libitm/configure.ac   | 6 --
>  libsanitizer/configure.ac | 9 +
>  libsanitizer/libbacktrace/Makefile.am | 2 --
>  6 files changed, 25 insertions(+), 11 deletions(-)

Hi, thanks for the patch, I personally support it (assuming it goes
along with a regeneration of the configure scripts). Reading it,
though, reminded me of another quibble I had about warning options
used when building GCC: The GCC docs for -Wextra say "(This option
used to be called -W. The older name is still supported, but the newer
name is more descriptive.)" See:
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options
This to me seems to imply that -Wextra is the preferred name, and that
the old name of -W should be replaced by it. Could we also make a
change to rename all instances of -W in configure scripts to -Wextra
too? Just a thought.
Thanks,
Eric

>
> diff --git a/libatomic/configure.ac b/libatomic/configure.ac
> index f350b9b3509..5a9f69bb74d 100644
> --- a/libatomic/configure.ac
> +++ b/libatomic/configure.ac
> @@ -251,10 +251,12 @@ LIBAT_ENABLE_SYMVERS
>  CFLAGS="$save_CFLAGS"
>  AC_CACHE_SAVE
>
> +AC_ARG_ENABLE([werror], [
> +  AS_HELP_STRING([--enable-werror], [turns on -Werror @<:@default=yes@:>@])])
>  # Add -Wall -Werror if we are using GCC.
> -if test "x$GCC" = "xyes"; then
> +AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
>XCFLAGS="$XCFLAGS -Wall -Werror"
> -fi
> +])
>
>  # Add CET specific flags if CET is enabled
>  GCC_CET_FLAGS(CET_FLAGS)
> diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
> index 0dfd82bc03e..a2858e6ecde 100644
> --- a/libbacktrace/configure.ac
> +++ b/libbacktrace/configure.ac
> @@ -145,10 +145,11 @@ ACX_PROG_CC_WARNING_OPTS([-W -Wall -Wwrite-strings 
> -Wstrict-prototypes \
>   -Wmissing-format-attribute -Wcast-qual],
>   [WARN_FLAGS])
>
> -if test -n "${with_target_subdir}"; then
> +AC_ARG_ENABLE([werror], [
> +  AS_HELP_STRING([--enable-werror], [turns on -Werror @<:@default=yes@:>@])])
> +AS_IF([test "x$enable_werror" != "xno" && test -n "${with_target_subdir}"], [
>WARN_FLAGS="$WARN_FLAGS -Werror"
> -fi
> -
> +])
>  AC_SUBST(WARN_FLAGS)
>
>  if test -n "${with_target_subdir}"; then
> diff --git a/libgomp/configure.ac b/libgomp/configure.ac
> index bfb613b91f0..c3062dc5a07 100644
> --- a/libgomp/configure.ac
> +++ b/libgomp/configure.ac
> @@ -121,10 +121,12 @@ AC_SUBST(CFLAGS)
>  # in both places for now and restore CFLAGS at the end of config.
>  save_CFLAGS="$CFLAGS"
>
> +AC_ARG_ENABLE([werror], [
> +  AS_HELP_STRING([--enable-werror], [turns on -Werror @<:@default=yes@:>@])])
>  # Add -Wall -Werror if we are using GCC.
> -if test "x$GCC" = "xyes"; then
> +AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
>XCFLAGS="$XCFLAGS -Wall -Werror"
> -fi
> +])
>
>  # Find other programs we need.
>  AC_CHECK_TOOL(AR, ar)
> diff --git a/libitm/configure.ac b/libitm/configure.ac
> index ac81b146845..ad99d14098e 100644
> --- a/libitm/configure.ac
> +++ b/libitm/configure.ac
> @@ -261,10 +261,12 @@ GCC_CHECK_ELF_STYLE_WEAKREF
>  CFLAGS="$save_CFLAGS"
>  AC_CACHE_SAVE
>
> +AC_ARG_ENABLE([werror], [
> +  AS_HELP_STRING([--enable-werror], [turns on -Werror @<:@default=yes@:>@])])
>  # Add -Wall -Werror if we are using GCC.
> -if test "x$GCC" = "xyes"; then
> +AS_IF([test "x$enable_werror" != "xno" && test "x$GCC" = "xyes"], [
>XCFLAGS="$XCFLAGS -Wall -Werror"
> -fi
> +])
>
>  XCFLAGS="$XCFLAGS $XPCFLAGS"
>
> diff --git a/libsanitizer/configure.ac b/libsanitizer/configure.ac
> index 13cd302030d..64eb42afc83 100644
> --- a/libsanitizer/configure.ac
> +++ b/libsanitizer/configure.ac
> @@ -400,6 +400,15 @@ fi
>  AC_SUBST([TSAN_TARGET_DEPENDENT_OBJECTS])
>  AC_SUBST([SANITIZER_COMMON_TARGET_DEPENDENT_OBJECTS])
>
> +AC_ARG_ENABLE([werror], [
> +  AS_HELP_STRING([--enable-werror], [turns on -Werror @<:@default=yes@:>@])])
> +
> +WARN_FLAGS="-W -Wall -Wwrite-strings -Wmissing-format-attribute -Wcast-qual"
> +AS_IF([test "x$enable_werror" != "xno"], [
> +  WARN_FLAGS="$WARN_FLAGS -Werror"
> +])
> +AC_SUBST([WARN_FLAGS])
> +
>  # Determine what GCC version number to use in filesystem paths.
>  GCC_BASE_VER
>
> diff --git a/libsanitizer/libbacktrace/Makefile.am 
> b/libsanitizer/libbacktrace/Makefile.am
> index 16accd468df..0cf8d2104c0 100644
> --- a/libsanitizer/libbacktrace/Makefile.am
> +++ b/libsanitizer/libbacktrace/Makefile.am
> @@ -34,8 +34,6 @@ ACLOCAL_AMFLAGS = -I ../.. -I ../../config
>  AM_CPPFLAGS = 

Re: [RFC] Port git gcc-descr to Python

[Eric Gallager via Gcc-patches]

On Wed, Jan 19, 2022 at 8:18 AM Martin Liška  wrote:
>
> On 1/19/22 13:49, Martin Jambor wrote:
> > Hi,
> >
> > On Wed, Jan 19 2022, Martin Liška wrote:
> >> On 10/18/21 11:01, Martin Liška wrote:
> >>> On 10/12/21 10:59, Martin Liška wrote:
>  Hello.
> 
>  There's a complete patch that implements both git gcc-descr and 
>  gcc-undesrc
>  and sets corresponding git aliases to use them.
> 
>  Ready to be installed?
>  Thanks,
>  Martin
> >>>
> >>> All right, so Jakub told me at IRC that we doesn't support porting to 
> >>> Python.
> >>> However, he promised supporting the changes I made in the original shell 
> >>> script.
> >>
> >> @Jakub: May I remind this, please?
> >
> > putting the following line in ..git/config seems to do the trick?
> >
> >   gcc-descr = "!f() { if test ${1:-no} = --short; then c=${2:-master}; 
> > r=$(git describe --all --match 'basepoints/gcc-[0-9]*' $c | sed -n 
> > 's,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*$,r\\2-\\3,p;s,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)$,r\\2-0,p');
> >  elif test ${1:-no} = --full; then c=${2:-master}; r=$(git describe --all 
> > --abbrev=40 --match 'basepoints/gcc-[0-9]*' $c | sed -n 
> > 's,^\\(tags/\\)\\?basepoints/gcc-,r,p'); else c=${1:-master}; r=$(git 
> > describe --all --abbrev=14 --match 'basepoints/gcc-[0-9]*' $c | sed -n 
> > 's,^\\(tags/\\)\\?basepoints/gcc-,r,p'); expr match ${r:-no} '^r[0-9]\\+$' 
> > >/dev/null && r=${r}-0-g$(git rev-parse ${2:-master}); fi; if test -n $r; 
> > then o=$(git config --get gcc-config.upstream); rr=$(echo $r | sed -n 
> > 's,^r\\([0-9]\\+\\)-[0-9]\\+\\(-g[0-9a-f]\\+\\)\\?$,\\1,p'); if git 
> > rev-parse --verify --quiet ${o:-origin}/releases/gcc-$rr >/dev/null; then 
> > m=releases/gcc-$rr; else m=master; fi; git merge-base --is-ancestor $c 
> > ${o:-origin}/$m && \\echo ${r}; fi; }; f"
> >
> > Derived from the following before squashing all the new lines:
> >
> >  if test ${1:-no} = --short; then
> >   c=${2:-master};
> >   r=$(git describe --all --match 'basepoints/gcc-[0-9]*' $c | sed -n 
> > 's,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*$,r\\2-\\3,p;s,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)$,r\\2-0,p');
> >  elif test ${1:-no} = --long; then
> >   c=${2:-master};
> >   r=$(git describe --all --abbrev=40 --match 'basepoints/gcc-[0-9]*' $c 
> > | sed -n 's,^\\(tags/\\)\\?basepoints/gcc-,r,p');
> >  else
> >   c=${1:-master};
> >   r=$(git describe --all --abbrev=14 --match 'basepoints/gcc-[0-9]*' $c 
> > | sed -n 's,^\\(tags/\\)\\?basepoints/gcc-,r,p');
> >   expr match ${r:-no} '^r[0-9]\\+$' >/dev/null && r=${r}-0-g$(git 
> > rev-parse ${2:-master});
> >  fi;
> >  if test -n $r; then
> >   o=$(git config --get gcc-config.upstream);
> >   rr=$(echo $r | sed -n 
> > 's,^r\\([0-9]\\+\\)-[0-9]\\+\\(-g[0-9a-f]\\+\\)\\?$,\\1,p');
> >   if git rev-parse --verify --quiet ${o:-origin}/releases/gcc-$rr 
> > >/dev/null; then
> >   m=releases/gcc-$rr;
> >   else
> >   m=master;
> >   fi;
> >   git merge-base --is-ancestor $c ${o:-origin}/$m && \\echo ${r};
> >  fi;
>
> Anyway, can we please put the nicely formatted bash script to 
> contrib/git-describe.sh (contrib/git-undescribe.sh), having that squashed
> to one line is just crazy.
>
> Martin, can you please do that?
>
> >
> >
> > (And if you wanted to ask then no, I am not touching
> > contrib/gcc-git-customization.sh, not even with a long pole, it scares
> > me :-)
>
> Sure, I can then adjust it if we end up with an outlined version where to code
> sits in proper .sh files.
>
> Martin
>
> >
> > Martin
> >
>

Hi, while people are modifying contrib/gcc-git-customization.sh, could
I get someone to take a look at bug 102644, too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664
Thanks,
Eric

Re: [PATCH] PR target/32803: Add -Oz option for improved clang compatibility.

[Eric Gallager via Gcc-patches]

On Tue, Dec 14, 2021 at 6:33 PM Jeff Law via Gcc-patches
 wrote:
>
>
>
> On 12/13/2021 5:27 PM, Joseph Myers wrote:
> > This is missing an invoke.texi update for the new option.
> And that update should probably note that -Oz turns on O2.  OK with that
> change.
>
> jeff

A news entry for the new optimization option would also be nice to
have in gcc-12/changes.html (in gcc-wwwdocs), so that people can know
it's available.

Re: [PATCH] c++: Avoid narrowing in make_char_string_pack

[Eric Gallager via Gcc-patches]

On Fri, Dec 17, 2021 at 5:59 PM Marek Polacek via Gcc-patches
 wrote:
>
> This fixes
>
> gcc/cp/parser.c:4618:41: warning: narrowing conversion of '(char)(*(str + 
> ((sizetype)i)))' from 'char' to 'unsigned char' [-Wnarrowing]
>  4618 |   unsigned char s[3] = { '\'', str[i], '\'' };
>   |~^
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>

Hi, I thought that GCC was built with -Wno-narrowing; has that changed
since I last checked? I'd support a move to officially switch from
disabling -Wnarrowing to enabling it instead if that's possible and
hasn't been done yet. Also the '(char)(*(str + ((sizetype)i)))' looks
like some implementation details leaking; is there a bug against
-Wnarrowing (or the diagnostics system in general) open about that?

> gcc/cp/ChangeLog:
>
> * parser.c (make_char_string_pack): Add a cast to const unsigned
> char *.
> ---
>  gcc/cp/parser.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
> index 44eed7ea638..56232ab029f 100644
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -4607,7 +4607,8 @@ make_char_string_pack (tree value)
>  {
>tree charvec;
>tree argpack = make_node (NONTYPE_ARGUMENT_PACK);
> -  const char *str = TREE_STRING_POINTER (value);
> +  const unsigned char *str
> += (const unsigned char *) TREE_STRING_POINTER (value);
>int i, len = TREE_STRING_LENGTH (value) - 1;
>tree argvec = make_tree_vec (1);
>
>
> base-commit: d7ca2a79b82c6500ead6ab983d14c609e2124eee
> --
> 2.33.1
>

Re: [PATCH] config.gcc: Obsolete m32c-rtems target

[Eric Gallager via Gcc-patches]

On Fri, Dec 17, 2021 at 11:11 AM Joel Sherrill  wrote:
>
> ---
>  gcc/config.gcc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index c8824367b13..fe93a72a16c 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -252,6 +252,7 @@ case ${target} in
>   | cr16-*-*\
>   | hppa[12]*-*-hpux10* \
>   | hppa[12]*-*-hpux11* \
> + | m32c-*-rtems*   \
>   )
>  if test "x$enable_obsolete" != xyes; then
>echo "*** Configuration ${target} is obsolete." >&2
> --
> 2.24.4
>

Hi, be sure to note this obsoletion in the Caveats section of
gcc-12/changes.html; thanks.

Re: [PATCH] gcc/diagnostic.c: make -Werror message more helpful

[Eric Gallager via Gcc-patches]

On Tue, Dec 14, 2021 at 1:33 PM Eric Gallager  wrote:
>
> On Mon, Dec 13, 2021 at 1:17 PM Martin Sebor via Gcc-patches
>  wrote:
> >
> > On 12/12/21 3:13 AM, Andrea Monaco via Gcc-patches wrote:
> > >
> > > Hello.
> > >
> > >
> > > I propose to make that message more verbose.  It sure would have helped
> > > me once.  You don't always have a Web search available :)
> >
> > Warnings turned into errors have the [-Werror=...] tag at the end
> > so I'm not sure I see when reiterating -Werror at the end of output
> > would be helpful.  Can you explain the circumstances when it would
> > have helped you?
> >
> > For what it's worth, a change here that I think might be more useful
> > is printing the number of diagnostics of each kind (e.g., 2 warnings
> > and 5 errors found).
> >
>
> I swear we already had a bug open for this suggestion, but after much
> searching I can't seem to find it anymore, so if anyone has any ideas
> of what keywords I forgot to try, feel free to send them...

Never mind, I managed to find it after all: it's bug 26061:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26061

> > > Andrea Monaco
> > >
> > >
> > >
> > > diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
> > > index 4ded1760705..8b67662390e 100644
> > > --- a/gcc/diagnostic.c
> > > +++ b/gcc/diagnostic.c
> > > @@ -156,7 +156,7 @@ default_diagnostic_final_cb (diagnostic_context 
> > > *context)
> > > /* -Werror was given.  */
> > > if (context->warning_as_error_requested)
> > >  pp_verbatim (context->printer,
> > > -_("%s: all warnings being treated as errors"),
> > > +_("%s: all warnings being treated as errors 
> > > (-Werror; disable with -Wno-error)"),
> >
> > If this change should move forward, -Werror needs to be quoted
> > (e.g., passed as an argument to %qs or surrounded in a pair of
> > %< and %> directives).  The "disable with -Wno-error" part
> > is superfluous and would not be entirely accurate for warnings
> > promoted to errors by #pragma GCC diagnostic (those cannot be
> > demoted back to warnings by -Wno-error).
> >
> > Martin
> >
> > >   progname);
> > > /* At least one -Werror= was given.  */
> > > else
> > >
> >

Re: [PATCH] gcc/diagnostic.c: make -Werror message more helpful

[Eric Gallager via Gcc-patches]

On Mon, Dec 13, 2021 at 1:17 PM Martin Sebor via Gcc-patches
 wrote:
>
> On 12/12/21 3:13 AM, Andrea Monaco via Gcc-patches wrote:
> >
> > Hello.
> >
> >
> > I propose to make that message more verbose.  It sure would have helped
> > me once.  You don't always have a Web search available :)
>
> Warnings turned into errors have the [-Werror=...] tag at the end
> so I'm not sure I see when reiterating -Werror at the end of output
> would be helpful.  Can you explain the circumstances when it would
> have helped you?
>
> For what it's worth, a change here that I think might be more useful
> is printing the number of diagnostics of each kind (e.g., 2 warnings
> and 5 errors found).
>

I swear we already had a bug open for this suggestion, but after much
searching I can't seem to find it anymore, so if anyone has any ideas
of what keywords I forgot to try, feel free to send them...

> > Andrea Monaco
> >
> >
> >
> > diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
> > index 4ded1760705..8b67662390e 100644
> > --- a/gcc/diagnostic.c
> > +++ b/gcc/diagnostic.c
> > @@ -156,7 +156,7 @@ default_diagnostic_final_cb (diagnostic_context 
> > *context)
> > /* -Werror was given.  */
> > if (context->warning_as_error_requested)
> >  pp_verbatim (context->printer,
> > -_("%s: all warnings being treated as errors"),
> > +_("%s: all warnings being treated as errors (-Werror; 
> > disable with -Wno-error)"),
>
> If this change should move forward, -Werror needs to be quoted
> (e.g., passed as an argument to %qs or surrounded in a pair of
> %< and %> directives).  The "disable with -Wno-error" part
> is superfluous and would not be entirely accurate for warnings
> promoted to errors by #pragma GCC diagnostic (those cannot be
> demoted back to warnings by -Wno-error).
>
> Martin
>
> >   progname);
> > /* At least one -Werror= was given.  */
> > else
> >
>

Re: [PATCH] pch: Add support for relocation of the PCH data [PR71934]

[Eric Gallager via Gcc-patches]

On Wed, Dec 8, 2021 at 6:10 PM Jeff Law via Gcc-patches
 wrote:
>
>
>
> On 12/7/2021 2:55 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > The following patch adds support for relocation of the PCH blob on PCH
> > restore if we don't manage to get the preferred map slot for it.
> > The GTY stuff knows where all the pointers are, after all it relocates
> > it once during PCH save from the addresses where it was initially allocated
> > to addresses in the preferred map slot.
> > But, if we were to do it solely using GTY info upon PCH restore, we'd need
> > another set of GTY functions, which I think would make it less maintainable
> > and I think it would also be more costly at PCH restore time.  Those
> > functions would need to call something to add bias to pointers that haven't
> > been marked yet and make sure not to add bias to any pointer twice.
> >
> > So, this patch instead builds a relocation table (sorted list of addresses
> > in the blob which needs relocation) at PCH save time, stores it in a very
> > compact form into the gch file and upon restore, adjusts pointers in GTY
> > roots (that is right away in the root structures) and the addresses in the
> > relocation table.
> > The cost on stdc++.gch/O2g.gch (previously 85MB large) is about 3% file size
> > growth, there are 2.5 million pointers that need relocation in the gch blob
> > and the relocation table uses uleb128 for address deltas and needs ~1.01 
> > bytes
> > for one address that needs relocation, and about 20% compile time during
> > PCH save (I think it is mainly because of the need to qsort those 2.5
> > million pointers).  On PCH restore, if it doesn't need relocation (the usual
> > case), it is just an extra fread of sizeof (size_t) data and fseek
> > (in my tests real time on vanilla tree for #include  CU
> > was ~0.175s and with the patch but no relocation ~0.173s), while if it needs
> > relocation it took ~0.193s, i.e. 11.5% slower.
> >
> > The discovery of the pointers in the blob that need relocation is done
> > in the relocate_ptrs hook which does the pointer relocation during PCH save.
> > Unfortunately, I had to make one change to the gengtype stuff due to the
> > nested_ptr feature of GTY, which some libcpp headers and stringpool.c use.
> > The relocate_ptrs hook had 2 arguments, pointer to the pointer and a cookie.
> > When relocate_ptrs is done, in most cases it is called solely on the
> > subfields of the current object, so e.g.
> >if ((void *)(x) == this_obj)
> >  op (&((*x).u.fld[0].rt_rtx), cookie);
> > so relocate_ptrs can assert that ptr_p is within the
> > state->ptrs[state->ptrs_i]->obj ..
> > state->ptrs[state->ptrs_i]->obj+state->ptrs[state->ptrs_i]->size-sizeof(void*)
> > range and compute from that the address in the blob which will need
> > relocation (state->ptrs[state->ptrs_i]->new_addr is the new address
> > given to it and ptr_p-state->ptrs[state->ptrs_i]->obj is the relative
> > offset.  Unfortunately, for nested_ptr gengtype emits something like:
> >{
> >  union tree_node * x0 =
> >((*x).val.node.node) ? HT_IDENT_TO_GCC_IDENT (HT_NODE 
> > (((*x).val.node.node))) : NULL;
> >  if ((void *)(x) == this_obj)
> >op (&(x0), cookie);
> >  (*x).val.node.node = (x0) ? CPP_HASHNODE (GCC_IDENT_TO_HT_IDENT 
> > ((x0))) : NULL;
> >}
> > so relocate_ptrs is called with an address of some temporary variable and
> > so doesn't know where the pointer will finally be.
> > So, I've added another argument to relocate_ptrs (and to
> > gt_pointer_operator).  For the most common case I pass NULL as the new 
> > middle
> > argument to that function, first one remains pointer to the pointer that
> > needs adjustment and last the cookie.  The NULL seems to be cheap to compute
> > and short in the gt*.[ch] files and stands for ptr_p is an address within
> > the this_obj's range, remember its address.  For the nested_ptr case, the
> > new middle argument contains actual address of the pointer that might need
> > to be relocated, so instead of the above
> >op (&(x0), &((*x).val.node.node), cookie);
> > in there.  And finally, e.g. for the reorder case I need a way to tell
> > restore_ptrs to ignore a particular address for the relocation purposes
> > and only treat it the old way.  I've used for that the case when
> > the first and second arguments are equal.
> >
> > In order to enable support for mapping PCH as fallback at different
> > addresses than the preferred ones, a small change is needed to the
> > host pch_use_address hooks.  One change I've done to all of them is
> > the change of the type of the first argument from void * to void *&,
> > such that the actual address can be told to the callers (or shall I
> > instead use void **?), but another change that still needs to be done
> > in them if they want the relocation is actually not fail if they couldn't
> > get a preferred address, but instead modify what the first argument
> 

Re: [PATCH][wwwdocs] Update section on enormous source files in htdocs/projects/beginner.html

[Eric Gallager via Gcc-patches]

On Wed, Dec 1, 2021 at 10:54 AM Gerald Pfeifer  wrote:
>
> Hi Eric,
>
> On Wed, 24 Nov 2021, Eric Gallager wrote:
> > This next patch does more than just removing old stuff: it adds an
> > extra sentence to describe a shell command used to generate a list, so
> > to verify that I've got the shell command right, I'm asking for a
> > review.
>
> -There are several other files in this size range, which I have left
> +There are several other files in this size range, which are left
>  out because touching them at all is unwise (reload, the Fortran front
>  end).  You can try, but I am not responsible for any damage to your
>  sanity which may result.
>
> while we are touching this, how about toning the second half of this
> paragraph down and moving away from first person?
>
> How about something like "...breaking them up likely may prove rather
> difficult" (or similar, happy to leave this to you as native spaker)?
>

OK yeah I did remove the first instance of the first person in that
paragraph, but couldn't think of a better wording for the second one,
so that suggestion is helpful; thanks.

>
> +Note that the list of large files in this section is generated with the
> +following shell command, run from the gcc subdirectory:
> +
> +
> +   du -sh *.{c,h,cc} */*.{c,h,cc} | sort -hr | grep -v fortran | head -n 
> 14
> +
>
> This looks like it does what you want it to do.
>
> (Pulling up the database courses I have given in a previous life, I'd pull
> in the grep before the sort - O(n) filtering before O(n·log n) processing
> - but even on my notebook both are instantenous. ;-) )
>
>
> Please consider the two suggestions above and commit the result; just
> share the final patch here (no review required).
>
> Thanks,
> Gerald

OK thanks, I committed the attached patch as f4b4d0f:
https://gcc.gnu.org/git/?p=gcc-wwwdocs.git;a=commitdiff;h=f4b4d0f783246dd6f58944cdb542446d5e7589d3


patch-beginner-projects-02.diff
Description: Binary data

PING [PATCH][wwwdocs] Update section on enormous source files in htdocs/projects/beginner.html

[Eric Gallager via Gcc-patches]

Hi, I'd like to ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585294.html

On Wed, Nov 24, 2021 at 2:11 AM Eric Gallager  wrote:
>
> On Tue, Nov 23, 2021 at 6:27 PM Eric Gallager  wrote:
> >
> > On Fri, Nov 19, 2021 at 8:14 AM Eric Gallager  wrote:
> > >
> > > On Fri, Nov 19, 2021 at 1:48 AM Gerald Pfeifer  wrote:
> > > >
> > > > Cool, thank you!
> > > >
> > > > Please feel free to commit patches like this without asking for
> > > > approval (though I'm happy to review and approve).
> > > >
> > > > Gerald
> > > >
> > >
> > > OK thanks; committed as dbaebcd
> >
> > I've also committed one to remove the section on traditional C now:
> > https://gcc.gnu.org/git/?p=gcc-wwwdocs.git;a=commitdiff;h=ca83c13ad6bf0d351220dafa36264ebc7a6b7816
>
> This next patch does more than just removing old stuff: it adds an
> extra sentence to describe a shell command used to generate a list, so
> to verify that I've got the shell command right, I'm asking for a
> review.
>
> Thanks,
> Eric Gallager

Re: [PATCH] Make the path to etags used in the build system configurable [PR103021]

[Eric Gallager via Gcc-patches]

On Mon, Nov 29, 2021 at 9:48 AM Jeff Law  wrote:
>
>
>
> On 11/28/2021 6:34 PM, Eric Gallager via Gcc-patches wrote:
> > The attached patch allows users to specify a path to their `etags`
> > executable for use when doing `make tags`, which is meant to close PR
> > other/103021: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103021
> > I based this patch off of this one from upstream automake:
> > https://git.savannah.gnu.org/cgit/automake.git/commit/m4?id=d2ccbd7eb38d6a4277d6f42b994eb5a29b1edf29
> > This means that I just supplied variables that the user can override
> > for the tags programs, rather than having the configure scripts
> > actually check for them. I handle etags and ctags separately because
> > the intl subdirectory has separate targets for them. Tested with `make
> > tags`; the changes I made work successfully, but some of the
> > subdirectories still have broken tags targets, so I had to switch to
> > `make -k tags` part way through. This isn't because of anything I did,
> > though; the `-k` flag is only necessary because of errors that were
> > already there before I touched anything. Also note that this patch
> > only affects the subdirectories that use handwritten Makefiles; the
> > ones that use automake will have to wait until we update the version
> > of automake used to be 1.16.4 or newer before they'll be fixed.
> OK for the trunk.
> jeff

OK thanks; committed as g:909b30a:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=909b30a17e71253772d2cb174d0dae6d0b8c9401

[PATCH] Make the path to etags used in the build system configurable [PR103021]

[Eric Gallager via Gcc-patches]

The attached patch allows users to specify a path to their `etags`
executable for use when doing `make tags`, which is meant to close PR
other/103021: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103021
I based this patch off of this one from upstream automake:
https://git.savannah.gnu.org/cgit/automake.git/commit/m4?id=d2ccbd7eb38d6a4277d6f42b994eb5a29b1edf29
This means that I just supplied variables that the user can override
for the tags programs, rather than having the configure scripts
actually check for them. I handle etags and ctags separately because
the intl subdirectory has separate targets for them. Tested with `make
tags`; the changes I made work successfully, but some of the
subdirectories still have broken tags targets, so I had to switch to
`make -k tags` part way through. This isn't because of anything I did,
though; the `-k` flag is only necessary because of errors that were
already there before I touched anything. Also note that this patch
only affects the subdirectories that use handwritten Makefiles; the
ones that use automake will have to wait until we update the version
of automake used to be 1.16.4 or newer before they'll be fixed.


patch-configurable-etags.diff
Description: Binary data

Re: [PATCH][RFC] middle-end/46476 - resurrect -Wunreachable-code

[Eric Gallager via Gcc-patches]

On Wed, Nov 24, 2021 at 10:22 AM Richard Biener via Gcc-patches
 wrote:
>
> This resurrects -Wunreachable-code and implements a warning for
> trivially unreachable code as of CFG construction.  Most problematic
> with this is the C/C++ frontend added 'return 0;' stmt in main
> which the patch handles for C++ like the C frontend already does
> by using BUILTINS_LOCATION.
>
> Another problem for future enhancement is that after CFG construction
> we no longer can point to the stmt making a stmt unreachable, so
> this implementation tries to warn on the first unreachable
> statement of a region.  It might be possible to retain a pointer
> to the stmt that triggered creation of a basic-block but I'm not
> sure how reliable that would be.
>
> So this is really a simple attempt for now, triggered by myself
> running into such a coding error.  As always, the perfect is the
> enemy of the good.
>
> It does not pass bootstrap (which enables -Wextra), because of the
> situation in g++.dg/Wunreachable-code-5.C where the C++ frontend
> prematurely elides conditions like if (! GATHER_STATISTICS) that
> evaluate to true - oddly enough it does _not_ do this for
> conditions evaluating to false ... (one of the
> c-c++-common/Wunreachable-code-2.c cases).
>
> Richard.

There are several bugs about reviving -Wunreachable-code open, all for
different aspects of it. Do we want to consider making it an umbrella
flag that's split into multiple sub-options?
Bug 46476, which you mentioned, was suggested to be
-Wunreachable-code-return specifically:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
Meanwhile, there's also bug 92479, for a warning to be named
-Wunreachable-code-break:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479
Then there's also bug 82100, which doesn't have a name suggested for
it yet: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82100
I think having separate flags for the 3 of these that are all enabled
by -Wunreachable-code as an umbrella would be good.

Eric

>
> 2021-11-24  Richard Biener  
>
> PR middle-end/46476
> * common.opt (Wunreachable-code): No longer ignored,
> add warn_unreachable_code variable, enable with -Wextra.
> * doc/invoke.texi (Wunreachable-code): Document.
> (Wextra): Amend.
> * tree-cfg.c (build_gimple_cfg): Move case label grouping...
> (execute_build_cfg): ... here after new -Wunreachable-code
> warnings.
> (warn_unreachable_code_post_cfg_build): New function.
> (mark_forward_reachable_blocks): Likewise.
> (reverse_guess_deadend): Likewise.
>
> gcc/cp/
> * decl.c (finish_function): Set input_location to
> BUILTINS_LOCATION around the code building the return 0
> for main().
>
> libgomp/
> * oacc-plugin.c (GOMP_PLUGIN_acc_default_dim): Remove spurious
> return.
>
> gcc/testsuite/
> * c-c++-common/Wunreachable-code-1.c: New testcase.
> * c-c++-common/Wunreachable-code-2.c: Likewise.
> * c-c++-common/Wunreachable-code-3.c: Likewise.
> * gcc.dg/Wunreachable-code-4.c: Likewise.
> * g++.dg/Wunreachable-code-5.C: Likewise.
> ---
>  gcc/common.opt|   4 +-
>  gcc/cp/decl.c |   9 +-
>  gcc/doc/invoke.texi   |   9 +-
>  .../c-c++-common/Wunreachable-code-1.c|   8 ++
>  .../c-c++-common/Wunreachable-code-2.c|   8 ++
>  .../c-c++-common/Wunreachable-code-3.c|  35 ++
>  gcc/testsuite/g++.dg/Wunreachable-code-5.C|  11 ++
>  gcc/testsuite/gcc.dg/Wunreachable-code-4.c|  10 ++
>  gcc/tree-cfg.c| 101 +-
>  libgomp/oacc-plugin.c |   1 -
>  10 files changed, 186 insertions(+), 10 deletions(-)
>  create mode 100644 gcc/testsuite/c-c++-common/Wunreachable-code-1.c
>  create mode 100644 gcc/testsuite/c-c++-common/Wunreachable-code-2.c
>  create mode 100644 gcc/testsuite/c-c++-common/Wunreachable-code-3.c
>  create mode 100644 gcc/testsuite/g++.dg/Wunreachable-code-5.C
>  create mode 100644 gcc/testsuite/gcc.dg/Wunreachable-code-4.c
>
> diff --git a/gcc/common.opt b/gcc/common.opt
> index 755e1a233b7..0a58cb8a668 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -806,8 +806,8 @@ Common Var(warn_maybe_uninitialized) Warning 
> EnabledBy(Wuninitialized)
>  Warn about maybe uninitialized automatic variables.
>
>  Wunreachable-code
> -Common Ignore Warning
> -Does nothing. Preserved for backward compatibility.
> +Common Var(warn_unreachable_code) Warning EnabledBy(Wextra)
> +Warn about trivially unreachable code.
>
>  Wunused
>  Common Var(warn_unused) Init(0) Warning
> diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
> index 588094b1db6..26325e41efa 100644
> --- a/gcc/cp/decl.c
> +++ b/gcc/cp/decl.c
> @@ -17571,7 +17571,14 @@ finish_function (bool inline_p)
>  {
>/* Make it so that `main' always returns 0 by default.  */
>if 

[PATCH][wwwdocs] Update section on enormous source files in htdocs/projects/beginner.html

[Eric Gallager via Gcc-patches]

On Tue, Nov 23, 2021 at 6:27 PM Eric Gallager  wrote:
>
> On Fri, Nov 19, 2021 at 8:14 AM Eric Gallager  wrote:
> >
> > On Fri, Nov 19, 2021 at 1:48 AM Gerald Pfeifer  wrote:
> > >
> > > Cool, thank you!
> > >
> > > Please feel free to commit patches like this without asking for
> > > approval (though I'm happy to review and approve).
> > >
> > > Gerald
> > >
> >
> > OK thanks; committed as dbaebcd
>
> I've also committed one to remove the section on traditional C now:
> https://gcc.gnu.org/git/?p=gcc-wwwdocs.git;a=commitdiff;h=ca83c13ad6bf0d351220dafa36264ebc7a6b7816

This next patch does more than just removing old stuff: it adds an
extra sentence to describe a shell command used to generate a list, so
to verify that I've got the shell command right, I'm asking for a
review.

Thanks,
Eric Gallager


patch-beginner-projects-02.diff
Description: Binary data

[committed][wwwdocs] Remove section on traditional C from htdocs/projects/beginner.html

[Eric Gallager via Gcc-patches]

On Fri, Nov 19, 2021 at 8:14 AM Eric Gallager  wrote:
>
> On Fri, Nov 19, 2021 at 1:48 AM Gerald Pfeifer  wrote:
> >
> > Cool, thank you!
> >
> > Please feel free to commit patches like this without asking for
> > approval (though I'm happy to review and approve).
> >
> > Gerald
> >
>
> OK thanks; committed as dbaebcd

I've also committed one to remove the section on traditional C now:
https://gcc.gnu.org/git/?p=gcc-wwwdocs.git;a=commitdiff;h=ca83c13ad6bf0d351220dafa36264ebc7a6b7816

Re: [PATCH][wwwdocs] remove references to java in htdocs/projects/beginner.html

[Eric Gallager via Gcc-patches]

On Fri, Nov 19, 2021 at 1:48 AM Gerald Pfeifer  wrote:
>
> On Thu, 18 Nov 2021, Eric Gallager wrote:
> > I'd find it easier to just edit the page linked to in wwwdocs instead,
> > so I'm going to start seeing what I can do to update it. I figured I'd
> > start by removing the references to Java in it, since Java has been
> > removed. A patch to do that is attached. Eric Gallager
>
> Cool, thank you!
>
> Please feel free to commit patches like this without asking for
> approval (though I'm happy to review and approve).
>
> Gerald
>

OK thanks; committed as dbaebcd

[PATCH][wwwdocs] remove references to java in htdocs/projects/beginner.html

[Eric Gallager via Gcc-patches]

So, on the wiki page for EasyHacks
, it says: "There is also a
non-wiki list of beginner projects at
http://gcc.gnu.org/projects/beginner.html, however, it is very
outdated and the projects are not that easy." Since I don't have an
account on the wiki (since creating a separate wiki account that's
different from my Bugzilla account would create difficulties for my
password manager), but I do have commit access, I'd find it easier to
just edit the page linked to in wwwdocs instead, so I'm going to start
seeing what I can do to update it. I figured I'd start by removing the
references to Java in it, since Java has been removed. A patch to do
that is attached.
Eric Gallager


patch-beginner-projects-01.diff
Description: Binary data

Re: [PATCH] fixincludes: don't assume getcwd() can handle NULL argument

[Eric Gallager via Gcc-patches]

On Tue, Nov 9, 2021 at 8:50 AM Xi Ruoyao via Gcc-patches
 wrote:
>
> POSIX says:
>
> On some implementations, if buf is a null pointer, getcwd() may obtain
> size bytes of memory using malloc(). In this case, the pointer returned
> by getcwd() may be used as the argument in a subsequent call to free().
> Invoking getcwd() with buf as a null pointer is not recommended in
> conforming applications.
>
> This produces an error building GCC with --enable-werror-always:
>
> ../../../fixincludes/fixincl.c: In function ‘process’:
> ../../../fixincludes/fixincl.c:1356:7: error: argument 1 is null but
> the corresponding size argument 2 value is 4096 [-Werror=nonnull]
>
> And, at least we've been leaking memory even if getcwd() supports this
> non-standard extension.
>
> fixincludes/ChangeLog:
>
> * fixincl.c (process): Allocate and deallocate the buffer for
>   getcwd() explicitly.
> ---
>  fixincludes/fixincl.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
> index 6dba2f6e830..b4b1e38ede7 100644
> --- a/fixincludes/fixincl.c
> +++ b/fixincludes/fixincl.c
> @@ -1353,9 +1353,11 @@ process (void)
>if (access (pz_curr_file, R_OK) != 0)
>  {
>int erno = errno;
> +  char *buf = xmalloc (MAXPATHLEN);
>fprintf (stderr, "Cannot access %s from %s\n\terror %d (%s)\n",
> -   pz_curr_file, getcwd ((char *) NULL, MAXPATHLEN),
> +   pz_curr_file, getcwd (buf, MAXPATHLEN),
> erno, xstrerror (erno));
> +  free (buf);
>return;
>  }
>
> --
> 2.33.1

This seems to contradict bug 21823:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823
It would fix bug 80047, though:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80047

Re: [PATCH 2/2] add -Wdangling-pointer [PR #63272]

[Eric Gallager via Gcc-patches]

On Mon, Nov 1, 2021 at 6:20 PM Martin Sebor via Gcc-patches
 wrote:
>
> Patch 2 in this series adds support for detecting the uses of
> dangling pointers: those to auto objects that have gone out of
> scope.  Like patch 1, to minimize false positives this detection
> is very simplistic.  However, thanks to the more deterministic
> nature of the problem (all local objects go out of scope) is able
> to detect more instances of it.  The approach I used is to simply
> search the IL for clobbers that dominate uses of pointers to
> the clobbered objects.  If such a use is found that's not
> followed by a clobber of the same object the warning triggers.
> Similar to -Wuse-after-free, the new -Wdangling-pointer option
> has multiple levels: level 1 to detect unconditional uses and
> level 2 to flag conditional ones.  Unlike with -Wuse-after-free
> there is no use case for testing dangling pointers for
> equality, so there is no level 3.
>
> Tested on x86_64-linux and  by building Glibc and Binutils/GDB.
> It found no problems outside of the GCC test suite.
>
> As with the first patch in this series, the tests contain a number
> of xfails due to known limitations marked with pr??.  I'll
> open bugs for them before committing the patch if I don't resolve
> them first in a followup.
>
> Martin

So, I'd just like to take this chance to re-state my preference (as a
user) for having separate named options for warnings instead of having
a single option with multiple levels, so that users can toggle just
one but not the other. With the numerical levels, one can detect only
unconditional uses, and not conditional ones, by using level one, but
they can't do it the other way around (i.e. detecting conditional
uses, but not unconditional ones), though. I think having a split like
the one that exists between -Wuninitialized and -Wmaybe-uninitialized
would make sense here.

Eric

Re: [PATCH 1/2] add -Wuse-after-free

[Eric Gallager via Gcc-patches]

On Mon, Nov 1, 2021 at 6:18 PM Martin Sebor via Gcc-patches
 wrote:
>
> Patch 1 in the series detects a small subset of uses of pointers
> made indeterminate by calls to deallocation functions like free
> or C++ operator delete.  To control the conditions the warnings
> are issued under the new -Wuse-after-free= option provides three
> levels.  At the lowest level the warning triggers only for
> unconditional uses of freed pointers and doesn't warn for uses
> in equality expressions.  Level 2 warns also for come conditional
> uses, and level 3 also for uses in equality expressions.
>
> I debated whether to make level 2 or 3 the default included in
> -Wall.  I decided on 3 for two reasons: 1) to raise awareness
> of both the problem and GCC's new ability to detect it: using
> a pointer after it's been freed, even only in principle, by
> a successful call to realloc, is undefined, and 2) because
> it's trivial to lower the level either globally, or locally
> by suppressing the warning around such misuses.
>
> I've tested the patch on x86_64-linux and by building Glibc
> and Binutils/GDB.  It triggers a number of times in each, all
> due to comparing invalidated pointers for equality (i.e., level
> 3).  I have suppressed these in GCC (libiberty) by a #pragma,
> and will see how the Glibc folks want to deal with theirs (I
> track them in BZ #28521).
>
> The tests contain a number of xfails due to limitations I'm
> aware of.  I marked them pr?? until the patch is approved.
> I will open bugs for them before committing if I don't resolve
> them in a followup.
>
> Martin

Hi, I'm just wondering how this fares compared to the static
analyzer's -Wanalyzer-use-after-free; could you compare and contrast
them for us?
Thanks,
Eric

Re: [PATCH] x86: Document -fcf-protection requires i686 or newer

[Eric Gallager via Gcc-patches]

On Thu, Oct 21, 2021 at 12:49 PM H.J. Lu via Gcc-patches
 wrote:
>
> PR target/98667
> * doc/invoke.texi: Document -fcf-protection requires i686 or
> new.
> ---
>  gcc/doc/invoke.texi | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index c66a25fcd69..71992b8c597 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -15542,7 +15542,8 @@ which functions and calls should be skipped from 
> instrumentation
>  (@pxref{Function Attributes}).
>
>  Currently the x86 GNU/Linux target provides an implementation based
> -on Intel Control-flow Enforcement Technology (CET).
> +on Intel Control-flow Enforcement Technology (CET) which works for
> +i686 processor or newer.

I think "processor" should be pluralized to "processors"? Also,
possibly a missing comma after "(CET)"?

>
>  @item -fstack-protector
>  @opindex fstack-protector
> --
> 2.32.0
>

Re: [PATCH] attribs: Allow optional second arg for attr deprecated [PR102049]

[Eric Gallager via Gcc-patches]

On Mon, Oct 11, 2021 at 11:19 AM Marek Polacek via Gcc-patches
 wrote:
>
> Any thoughts?

I think it's a good idea, but then again I can't approve it, so...
well, who can, then?

>
> On Thu, Sep 23, 2021 at 12:16:36PM -0400, Marek Polacek via Gcc-patches wrote:
> > Clang implements something we don't have:
> >
> > __attribute__((deprecated("message", "replacement")));
> >
> > which seems pretty neat so I wrote this patch to add it to gcc.
> >
> > It doesn't allow the optional second argument in the standard [[]]
> > form so as not to clash with possible future standard additions.
> >
> > I had hoped we could print a nice fix-it replacement hint, but that
> > won't be possible until warn_deprecated_use gets something better than
> > input_location.

Looking forward to the fix-it hint support being added!

> >
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> >   PR c++/102049
> >
> > gcc/c-family/ChangeLog:
> >
> >   * c-attribs.c (c_common_attribute_table): Increase max_len for
> >   deprecated.
> >   (handle_deprecated_attribute): Allow an optional second argument
> >   in the GNU form of attribute deprecated.
> >
> > gcc/c/ChangeLog:
> >
> >   * c-parser.c (c_parser_std_attribute): Give a diagnostic when
> >   the standard form of an attribute deprecated has a second argument.
> >
> > gcc/ChangeLog:
> >
> >   * doc/extend.texi: Document attribute deprecated with an
> >   optional second argument.
> >   * tree.c (warn_deprecated_use): Print the replacement argument,
> >   if any.
> >
> > gcc/testsuite/ChangeLog:
> >
> >   * gcc.dg/c2x-attr-deprecated-3.c: Adjust dg-error.
> >   * c-c++-common/Wdeprecated-arg-1.c: New test.
> > ---
> >  gcc/c-family/c-attribs.c  | 17 -
> >  gcc/c/c-parser.c  |  8 ++
> >  gcc/doc/extend.texi   | 24 ++
> >  .../c-c++-common/Wdeprecated-arg-1.c  | 21 
> >  gcc/testsuite/gcc.dg/c2x-attr-deprecated-3.c  |  2 +-
> >  gcc/tree.c| 25 +++
> >  6 files changed, 90 insertions(+), 7 deletions(-)
> >  create mode 100644 gcc/testsuite/c-c++-common/Wdeprecated-arg-1.c
> >
> > diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
> > index 007b928c54b..ef857a9ae2c 100644
> > --- a/gcc/c-family/c-attribs.c
> > +++ b/gcc/c-family/c-attribs.c
> > @@ -409,7 +409,7 @@ const struct attribute_spec c_common_attribute_table[] =
> >   to prevent its usage in source code.  */
> >{ "no vops",0, 0, true,  false, false, false,
> > handle_novops_attribute, NULL },
> > -  { "deprecated", 0, 1, false, false, false, false,
> > +  { "deprecated", 0, 2, false, false, false, false,
> > handle_deprecated_attribute, NULL },
> >{ "unavailable",0, 1, false, false, false, false,
> > handle_unavailable_attribute, NULL },
> > @@ -4107,6 +4107,21 @@ handle_deprecated_attribute (tree *node, tree name,
> >error ("deprecated message is not a string");
> >*no_add_attrs = true;
> >  }
> > +  else if (TREE_CHAIN (args) != NULL_TREE)
> > +{
> > +  /* We allow an optional second argument in the GNU form of
> > +  attribute deprecated, which specifies the replacement.  */
> > +  if (flags & ATTR_FLAG_CXX11)
> > + {
> > +   error ("replacement argument only allowed in GNU attributes");
> > +   *no_add_attrs = true;
> > + }
> > +  else if (TREE_CODE (TREE_VALUE (TREE_CHAIN (args))) != STRING_CST)
> > + {
> > +   error ("replacement argument is not a string");
> > +   *no_add_attrs = true;
> > + }
> > +}
> >
> >if (DECL_P (*node))
> >  {
> > diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> > index fa29d2c15fc..2b47f01d166 100644
> > --- a/gcc/c/c-parser.c
> > +++ b/gcc/c/c-parser.c
> > @@ -4952,6 +4952,14 @@ c_parser_std_attribute (c_parser *parser, bool 
> > for_tm)
> >   TREE_VALUE (attribute)
> > = c_parser_attribute_arguments (parser, takes_identifier,
> > require_string, false);
> > + if (c_parser_next_token_is (parser, CPP_COMMA)
> > + && strcmp (IDENTIFIER_POINTER (name), "deprecated") == 0)
> > +   {
> > + error_at (open_loc, "replacement argument only allowed in "
> > +   "GNU attributes");
> > + c_parser_skip_until_found (parser, CPP_CLOSE_PAREN, NULL);
> > + return error_mark_node;
> > +   }
> >}
> >  else
> >c_parser_balanced_token_sequence (parser);
> > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> > index 9501a60f20e..7d399f4b2bc 100644
> > --- a/gcc/doc/extend.texi
> > +++ b/gcc/doc/extend.texi
> > @@ -2860,6 +2860,7 @@ StrongAlias (allocate, alloc);
> >
> >  @item deprecated
> >  

Re: [PATCH] configure, d: Add support for bootstrapping the D front-end

[Eric Gallager via Gcc-patches]

On Thu, Oct 28, 2021 at 2:38 PM Jeff Law via Gcc-patches
 wrote:
>
>
>
> On 10/9/2021 7:32 AM, Iain Buclaw via Gcc-patches wrote:
> > Hi,
> >
> > The implementation of the D front-end in GCC is based on the original
> > C++ version of the D programming language compiler, which was ported to
> > D itself in version 2.069.0 (released in 2015).  To keep it somewhat
> > up-to-date, I have been backporting fixes from upstream back into C++,
> > but this stopped at version 2.076.1 (released in 2017), and since then
> > I've only been keeping the front-end only updated enough to still be
> > able to build the latest version of the D language (now 2.098.0).
> >
> > Reasons for putting off switching to the D implementation immediately
> > after GCC 9 has been a mixture of the front-end not being ready to use,
> > and current portability status of the D core runtime library.
> >
> > It has come to the point now that I'm happy enough with the process to
> > switch out the C++ sources in gcc/d/dmd with D sources.
> >
> > Before that, there's only this patch that makes the required changes to
> > GCC itself in order to have a D front-end written in D itself.
> >
> > The rest of the series only changes code in the D language front-end or
> > libphobos standard library, so I've left that out for the time being
> > until I'm ready to commit it.
> >
> > The complete set of changes are in the ibuclaw/gdc branch under
> > users/ibuclaw.  It has been well-tested on x86_64-linux-gnu for about 3
> > years now, and I've also been testing the self-hosted compiler on
> > powerpc64le-linux-gnu as well with no regressions from the D language
> > testsuite run.
> >
> > Does anything stand out as being problematic in this patch, or may need
> > splitting out first?  Or would it be OK for trunk?
> >
> > Thanks,
> > Iain.
> >
> > ---
> > ChangeLog:
> >
> >   * Makefile.def: Add bootstrap to libbacktrace, libphobos, zlib, and
> >   libatomic.
> >   * Makefile.in: Regenerate.
> >   * Makefile.tpl (POSTSTAGE1_HOST_EXPORTS): Fix command for GDC.
> >   (STAGE1_CONFIGURE_FLAGS): Add --with-libphobos-druntime-only if
> >   target-libphobos-bootstrap.
> >   (STAGE2_CONFIGURE_FLAGS): Likewise.
> >   * configure: Regenerate.
> >   * configure.ac: Add support for bootstrapping D front-end.
> >
> > config/ChangeLog:
> >
> >   * acx.m4 (ACX_PROG_GDC): New m4 function.
> >
> > gcc/ChangeLog:
> >
> >   * Makefile.in (GDC): New variable.
> >   (GDCFLAGS): New variable.
> >   * configure: Regenerate.
> >   * configure.ac: Add call to ACX_PROG_GDC.  Substitute GDCFLAGS.
> >
> > gcc/po/ChangeLog:
> >
> >   * EXCLUDES: Remove d/dmd sources from list.
> Presumably this means that the only way to build D for the first time on
> a new target is to cross from an existing target that supports D, right?
>
> I think that's not unreasonable and I don't think we want to increase
> the burden of maintaining an old codebase just for the sake of a
> marginally easier bootstrap process for a new target.
>
> So I think you should go with this whenever you're ready.
>
> jeff
>

There should be some sort of note about this in the documentation,
IMO; both install.texi and the "Caveats" section of
gcc-12/changes.html (and possibly other places).

Eric

Re: [PATCH] libcody: add mostlyclean Makefile target

[Eric Gallager via Gcc-patches]

On Tue, Oct 26, 2021 at 5:47 AM Martin Liška  wrote:
>
> On 10/25/21 18:10, Eric Gallager wrote:
> > On Mon, Oct 25, 2021 at 7:35 AM Martin Liška  wrote:
> >>
> >> Hello.
> >>
> >> The patch adds missing Makefile mostlyclean.
> >>
> >> Ready to be installed?
> >> Thanks,
> >> Martin
> >>
> >
> > Generally the way the various "*clean" targets are arranged, in order
> > of cleanliness, from least clean to most clean, is:
> > mostlyclean
> > clean
> > distclean
> > maintainer-clean
> > ...with each target depending on the previous one in the order. So
> > thus, instead of mostlyclean depending on clean, it'd be the other way
> > around, with clean depending on mostlyclean. See how the gcc/
> > subdirectory does it, for example. See the "Standard Targets for
> > Users" section of the GNU Coding Standards:
> > https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets
>
> Thank you for the explanation.
>
> There's updated version of the patch.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?

Hi, the patch looks ok to me, although I can't approve it... Who is
the libcody maintainer, anyways? Nathan? Should that be listed in the
MAINTAINERS file?
Thanks,
Eric Gallager

> Thanks,
> Martin
>
> >
> >>  PR other/102657
> >>
> >> libcody/ChangeLog:
> >>
> >>  * Makefile.in: Add mostlyclean Makefile target.
> >> ---
> >>libcody/Makefile.in | 4 +++-
> >>1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libcody/Makefile.in b/libcody/Makefile.in
> >> index b8b45a2e310..d8f1e8216d4 100644
> >> --- a/libcody/Makefile.in
> >> +++ b/libcody/Makefile.in
> >> @@ -111,7 +111,7 @@ maintainer-clean:: distclean
> >>clean::
> >>  rm -f $(shell find $(srcdir) -name '*~')
> >>
> >> -.PHONY: all check clean distclean maintainer-clean
> >> +.PHONY: all check clean distclean maintainer-clean mostlyclean
> >>
> >>CXXFLAGS/ := -I$(srcdir)
> >>LIBCODY.O := buffer.o client.o fatal.o netclient.o netserver.o \
> >> @@ -127,6 +127,8 @@ clean::
> >>  rm -f $(LIBCODY.O) $(LIBCODY.O:.o=.d)
> >>  rm -f libcody.a
> >>
> >> +mostlyclean: clean
> >> +
> >>CXXFLAGS/fatal.cc = -DSRCDIR='"$(srcdir)"'
> >>
> >>fatal.o: Makefile revision
> >> --
> >> 2.33.1
> >>

Re: [PATCH] libcody: add mostlyclean Makefile target

[Eric Gallager via Gcc-patches]

On Mon, Oct 25, 2021 at 7:35 AM Martin Liška  wrote:
>
> Hello.
>
> The patch adds missing Makefile mostlyclean.
>
> Ready to be installed?
> Thanks,
> Martin
>

Generally the way the various "*clean" targets are arranged, in order
of cleanliness, from least clean to most clean, is:
mostlyclean
clean
distclean
maintainer-clean
...with each target depending on the previous one in the order. So
thus, instead of mostlyclean depending on clean, it'd be the other way
around, with clean depending on mostlyclean. See how the gcc/
subdirectory does it, for example. See the "Standard Targets for
Users" section of the GNU Coding Standards:
https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets

> PR other/102657
>
> libcody/ChangeLog:
>
> * Makefile.in: Add mostlyclean Makefile target.
> ---
>   libcody/Makefile.in | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libcody/Makefile.in b/libcody/Makefile.in
> index b8b45a2e310..d8f1e8216d4 100644
> --- a/libcody/Makefile.in
> +++ b/libcody/Makefile.in
> @@ -111,7 +111,7 @@ maintainer-clean:: distclean
>   clean::
> rm -f $(shell find $(srcdir) -name '*~')
>
> -.PHONY: all check clean distclean maintainer-clean
> +.PHONY: all check clean distclean maintainer-clean mostlyclean
>
>   CXXFLAGS/ := -I$(srcdir)
>   LIBCODY.O := buffer.o client.o fatal.o netclient.o netserver.o \
> @@ -127,6 +127,8 @@ clean::
> rm -f $(LIBCODY.O) $(LIBCODY.O:.o=.d)
> rm -f libcody.a
>
> +mostlyclean: clean
> +
>   CXXFLAGS/fatal.cc = -DSRCDIR='"$(srcdir)"'
>
>   fatal.o: Makefile revision
> --
> 2.33.1
>

Re: (!HELP NEEDED) Where is the doc for the format strings in gcc (for example, %q+D, ...)

[Eric Gallager via Gcc-patches]

On Wed, Oct 20, 2021 at 10:57 AM Marek Polacek via Gcc-patches
 wrote:
>
> On Wed, Oct 20, 2021 at 03:49:09PM +, Qing Zhao via Gcc-patches wrote:
> > Hi,
> >
> > In GCC, there are many utility routines for reporting error, warning, or 
> > information, for example:
> >
> > warning (0, "weak declaration of %q+D not supported", decl);
> > warning_at (stmtloc, OPT_Wmaybe_uninitialized,  "%qE may be used 
> > uninitialized", ptr));
> > inform (loc, "in a call to %qT declared with " "attribute %<%s%>", fntype, 
> > access_str);
> > error ("%qD is unavailable: %s", node, (const char *) msg);
> >
> > There are format-strings inside them, “%q+D”, “%qE”, “%qT”, “%qD”, etc, 
> > where can I find a doc for the details of
> > These format-strings? Or which source files I should read to understand the 
> > details?
>
> You can take a look at cp/error.c:
>
> /* Called from output_format -- during diagnostic message processing --
>to handle C++ specific format specifier with the following meanings:
>%A   function argument-list.
>%C   tree code.
>%D   declaration.
>%E   expression.
>%F   function declaration.
>%H   type difference (from).
>%I   type difference (to).
>%L   language as used in extern "lang".
>%O   binary operator.
>%P   function parameter whose position is indicated by an integer.
>%Q   assignment operator.
>%S   substitution (template + args)
>%T   type.
>%V   cv-qualifier.
>%X   exception-specification.  */
> static bool
> cp_printer (pretty_printer *pp, text_info *text, const char *spec,
>
> or c/c-objc-common.c:
>
> /* Called during diagnostic message formatting process to print a
>source-level entity onto BUFFER.  The meaning of the format specifiers
>is as follows:
>%D: a general decl,
>%E: an identifier or expression,
>%F: a function declaration,
>%T: a type.
>%V: a list of type qualifiers from a tree.
>%v: an explicit list of type qualifiers
>%#v: an explicit list of type qualifiers of a function type.
>
>Please notice when called, the `%' part was already skipped by the
>diagnostic machinery.  */
> static bool
> c_tree_printer (pretty_printer *pp, text_info *text, const char *spec,
>
> Marek
>

Note that this is bug 92435: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92435

Re: [PATCH][WIP] Add install-dvi Makefile targets

[Eric Gallager via Gcc-patches]

On Fri, Oct 22, 2021 at 8:23 AM Jeff Law  wrote:
>
>
>
> On 10/18/2021 7:30 PM, Eric Gallager wrote:
> > On Tue, Oct 12, 2021 at 5:09 PM Eric Gallager  wrote:
> >> On Thu, Oct 6, 2016 at 10:41 AM Eric Gallager  wrote:
> >>> Currently the build machinery handles install-pdf and install-html
> >>> targets, but no install-dvi target. This patch is a step towards
> >>> fixing that. Note that I have only tested with
> >>> --enable-languages=c,c++,lto,objc,obj-c++. Thus, target hooks will
> >>> probably also have to be added for the languages I skipped.
> >>> Also, please note that this patch applies on top of:
> >>> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00370.html
> >>>
> >>> ChangeLog:
> >>>
> >>> 2016-10-06  Eric Gallager  
> >>>
> >>>  * Makefile.def: Handle install-dvi target.
> >>>  * Makefile.tpl: Likewise.
> >>>  * Makefile.in: Regenerate.
> >>>
> >>> gcc/ChangeLog:
> >>>
> >>> 2016-10-06  Eric Gallager  
> >>>
> >>>  * Makefile.in: Handle dvidir and install-dvi target.
> >>>  * ./[c|cp|lto|objc|objcp]/Make-lang.in: Add dummy install-dvi
> >>>  target hooks.
> >>>  * configure.ac: Handle install-dvi target.
> >>>  * configure: Regenerate.
> >>>
> >>> libiberty/ChangeLog:
> >>>
> >>> 2016-10-06  Eric Gallager  
> >>>
> >>>  * Makefile.in: Handle dvidir and install-dvi target.
> >>>  * functions.texi: Regenerate.
> >> Ping. The prerequisite patch that I linked to previously has gone in now.
> >> I'm not sure if this specific patch still applies, though.
> >> Also note that I've opened a bug to track this issue:
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102663
> > Hi, I have updated this patch and tested it with more languages now; I
> > can now confirm that it works with ada, d, and fortran now. The only
> > languages that remain untested now are go (since I'm building on
> > darwin and go doesn't build on darwin anyways, as per bug 46986) and
> > jit (which I ran into a bug about that I brought up on IRC, and will
> > probably need to file on bugzilla). OK to install?
> Yea, I think this is OK.  We might need to adjust go/jit and perhaps
> other toplevel modules, but if those do show up as problems I think we
> can fault in those fixes.
>
> jeff

OK thanks, installed as r12-4636:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c3e80a16af287e804b87b8015307085399755cd4

Re: [PATCH][WIP] Add install-dvi Makefile targets

[Eric Gallager via Gcc-patches]

On Tue, Oct 19, 2021 at 1:41 AM Thomas Koenig  wrote:
>
> Hi Eric,
>
> > Hi, I have updated this patch and tested it with more languages now; I
> > can now confirm that it works with ada, d, and fortran now. The only
> > languages that remain untested now are go (since I'm building on
> > darwin and go doesn't build on darwin anyways, as per bug 46986) and
> > jit (which I ran into a bug about that I brought up on IRC, and will
> > probably need to file on bugzilla). OK to install?
>
> Fortran parts look good.
>
> Best regards
>
> Thomas

OK, thanks... so... at this point, who do I still need approval from
for the rest of it, then? Should I be cc-ing the build system
maintainers? The maintainers for all the rest of the subdirectories
I'm touching? Global reviewers? Someone else?
Thanks,
Eric Gallager

Re: [PATCH][WIP] Add install-dvi Makefile targets

[Eric Gallager via Gcc-patches]

On Tue, Oct 12, 2021 at 5:09 PM Eric Gallager  wrote:
>
> On Thu, Oct 6, 2016 at 10:41 AM Eric Gallager  wrote:
> >
> > Currently the build machinery handles install-pdf and install-html
> > targets, but no install-dvi target. This patch is a step towards
> > fixing that. Note that I have only tested with
> > --enable-languages=c,c++,lto,objc,obj-c++. Thus, target hooks will
> > probably also have to be added for the languages I skipped.
> > Also, please note that this patch applies on top of:
> > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00370.html
> >
> > ChangeLog:
> >
> > 2016-10-06  Eric Gallager  
> >
> > * Makefile.def: Handle install-dvi target.
> > * Makefile.tpl: Likewise.
> > * Makefile.in: Regenerate.
> >
> > gcc/ChangeLog:
> >
> > 2016-10-06  Eric Gallager  
> >
> > * Makefile.in: Handle dvidir and install-dvi target.
> > * ./[c|cp|lto|objc|objcp]/Make-lang.in: Add dummy install-dvi
> > target hooks.
> > * configure.ac: Handle install-dvi target.
> > * configure: Regenerate.
> >
> > libiberty/ChangeLog:
> >
> > 2016-10-06  Eric Gallager  
> >
> > * Makefile.in: Handle dvidir and install-dvi target.
> > * functions.texi: Regenerate.
>
> Ping. The prerequisite patch that I linked to previously has gone in now.
> I'm not sure if this specific patch still applies, though.
> Also note that I've opened a bug to track this issue:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102663

Hi, I have updated this patch and tested it with more languages now; I
can now confirm that it works with ada, d, and fortran now. The only
languages that remain untested now are go (since I'm building on
darwin and go doesn't build on darwin anyways, as per bug 46986) and
jit (which I ran into a bug about that I brought up on IRC, and will
probably need to file on bugzilla). OK to install?


patch-install-dvi.diff
Description: Binary data

Re: [PATCH][WIP] Add install-dvi Makefile targets

[Eric Gallager via Gcc-patches]

On Thu, Oct 6, 2016 at 10:41 AM Eric Gallager  wrote:
>
> Currently the build machinery handles install-pdf and install-html
> targets, but no install-dvi target. This patch is a step towards
> fixing that. Note that I have only tested with
> --enable-languages=c,c++,lto,objc,obj-c++. Thus, target hooks will
> probably also have to be added for the languages I skipped.
> Also, please note that this patch applies on top of:
> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00370.html
>
> ChangeLog:
>
> 2016-10-06  Eric Gallager  
>
> * Makefile.def: Handle install-dvi target.
> * Makefile.tpl: Likewise.
> * Makefile.in: Regenerate.
>
> gcc/ChangeLog:
>
> 2016-10-06  Eric Gallager  
>
> * Makefile.in: Handle dvidir and install-dvi target.
> * ./[c|cp|lto|objc|objcp]/Make-lang.in: Add dummy install-dvi
> target hooks.
> * configure.ac: Handle install-dvi target.
> * configure: Regenerate.
>
> libiberty/ChangeLog:
>
> 2016-10-06  Eric Gallager  
>
> * Makefile.in: Handle dvidir and install-dvi target.
> * functions.texi: Regenerate.

Ping. The prerequisite patch that I linked to previously has gone in now.
I'm not sure if this specific patch still applies, though.
Also note that I've opened a bug to track this issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102663

Re: [PATCH] Allow `make tags` to work from top-level directory

[Eric Gallager via Gcc-patches]

On Tue, Oct 12, 2021 at 3:56 PM Eric Gallager  wrote:
>
> On Tue, Oct 12, 2021 at 9:18 AM Jeff Law  wrote:
> >
> >
> >
> > On 10/11/2021 4:05 PM, Eric Gallager via Gcc-patches wrote:
> > > On Thu, Oct 13, 2016 at 4:43 PM Eric Gallager  
> > > wrote:
> > >> On 10/13/16, Jeff Law  wrote:
> > >>> On 10/06/2016 07:21 AM, Eric Gallager wrote:
> > >>>> The libdecnumber, libgcc, and libobjc subdirectories are missing TAGS
> > >>>> targets in their Makefiles. The attached patch causes them to be
> > >>>> skipped when running `make tags`.
> > >>>>
> > >>>> ChangeLog entry:
> > >>>>
> > >>>> 2016-10-06  Eric Gallager  
> > >>>>
> > >>>>   * Makefile.def: Mark libdecnumber, libgcc, and libobjc as missing
> > >>>>   TAGS target.
> > >>>>   * Makefile.in: Regenerate.
> > >>>>
> > >>> OK.  Please install.
> > >>>
> > >>> Thanks,
> > >>> Jeff
> > >>>
> > >>
> > >> I'm still waiting to hear back from  about my request
> > >> for copyright assignment, which I'll need to get sorted out before I
> > >> can start committing stuff (like this patch).
> > >>
> > >> Thanks,
> > >> Eric
> > > Update: In the intervening years, I got my copyright assignment filed
> > > and have recently become able to commit again; is your old approval
> > > from 2016 still valid, Jeff, or do I need a re-approval?
> > > Ref: https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg00370.html
> > It's still valid.  Just re-test and commit.
> >
> > jeff
>
> While re-testing, it seems that the `etags` command on my computer
> can't be found any longer; I'm thinking gcc/Makefile.in should be
> updated to stop hardcoding etags and use a variable that can be
> overridden instead... should I do a separate patch for that, or
> combine it with this one?

Well, anyways, this is what I've ended up committing for now:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=4ca446a46bef8c127d7aaeb2d4bb4625edc7f84e


patch-Makefile.diff
Description: Binary data

Re: [PATCH] Allow `make tags` to work from top-level directory

[Eric Gallager via Gcc-patches]

On Tue, Oct 12, 2021 at 9:18 AM Jeff Law  wrote:
>
>
>
> On 10/11/2021 4:05 PM, Eric Gallager via Gcc-patches wrote:
> > On Thu, Oct 13, 2016 at 4:43 PM Eric Gallager  wrote:
> >> On 10/13/16, Jeff Law  wrote:
> >>> On 10/06/2016 07:21 AM, Eric Gallager wrote:
> >>>> The libdecnumber, libgcc, and libobjc subdirectories are missing TAGS
> >>>> targets in their Makefiles. The attached patch causes them to be
> >>>> skipped when running `make tags`.
> >>>>
> >>>> ChangeLog entry:
> >>>>
> >>>> 2016-10-06  Eric Gallager  
> >>>>
> >>>>   * Makefile.def: Mark libdecnumber, libgcc, and libobjc as missing
> >>>>   TAGS target.
> >>>>   * Makefile.in: Regenerate.
> >>>>
> >>> OK.  Please install.
> >>>
> >>> Thanks,
> >>> Jeff
> >>>
> >>
> >> I'm still waiting to hear back from  about my request
> >> for copyright assignment, which I'll need to get sorted out before I
> >> can start committing stuff (like this patch).
> >>
> >> Thanks,
> >> Eric
> > Update: In the intervening years, I got my copyright assignment filed
> > and have recently become able to commit again; is your old approval
> > from 2016 still valid, Jeff, or do I need a re-approval?
> > Ref: https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg00370.html
> It's still valid.  Just re-test and commit.
>
> jeff

While re-testing, it seems that the `etags` command on my computer
can't be found any longer; I'm thinking gcc/Makefile.in should be
updated to stop hardcoding etags and use a variable that can be
overridden instead... should I do a separate patch for that, or
combine it with this one?

Re: [PATCH] libiberty: prevent buffer overflow when decoding user input

[Eric Gallager via Gcc-patches]

On Tue, Oct 12, 2021 at 8:55 AM Luís Ferreira  wrote:
>
> On Fri, 2021-10-08 at 22:11 +0200, Iain Buclaw wrote:
> > Excerpts from Luís Ferreira's message of October 8, 2021 7:08 pm:
> > > On Fri, 2021-10-08 at 18:52 +0200, Iain Buclaw wrote:
> > > > Excerpts from Luís Ferreira's message of October 7, 2021 8:29 pm:
> > > > > On Tue, 2021-10-05 at 21:49 -0400, Eric Gallager wrote:
> > > > > >
> > > > > > I can help with the autotools part if you can say how precisely
> > > > > > you'd
> > > > > > like to use them to add address sanitization. And as for the
> > > > > > OSS
> > > > > > fuzz part, I think someone tried setting up auto-fuzzing for it
> > > > > > once,
> > > > > > but the main bottleneck was getting the bug reports that it
> > > > > > generated
> > > > > > properly triaged, so if you could make sure the bug-submitting
> > > > > > portion
> > > > > > of the process is properly streamlined, that'd probably go a
> > > > > > long
> > > > > > way
> > > > > > towards helping it be useful.
> > > > >
> > > > > Bugs are normally reported by email or mailing list. Is there any
> > > > > writable mailing list to publish bugs or is it strictly needed to
> > > > > open
> > > > > an entry on bugzilla?
> > > > >
> > > >
> > > > Please open an issue on bugzilla, fixes towards it can then be
> > > > referenced in the commit message/patch posted here.
> > > >
> > > > Iain.
> > >
> > > You mean for this current issue? The discussion was about future bug
> > > reports reported by the OSS fuzzer workers. I can also open an issue
> > > on
> > > the bugzilla for this issue, please clarify it and let me know :)
> > >
> >
> > 1. Open one for this issue.
> >
> > 2. Bugs found by the fuzzer would report to bugzilla.
> > https://gcc.gnu.org/bugs/
> >
> > Iain.
>
> Cross referencing the created issue:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102702
>
> --
> Sincerely,
> Luís Ferreira @ lsferreira.net
>

Right, I found the previous time someone tried to set up an autofuzzer
to report bugs to GCC's Bugzilla; searching for bugs reported by
security-...@google.com on Bugzilla should find them:
https://gcc.gnu.org/bugzilla/buglist.cgi?email1=security-tps%40google.com_to1=1=1=1=1=substring_id=326459_format=advanced

Re: [PATCH] Allow `make tags` to work from top-level directory

[Eric Gallager via Gcc-patches]

On Thu, Oct 13, 2016 at 4:43 PM Eric Gallager  wrote:
>
> On 10/13/16, Jeff Law  wrote:
> > On 10/06/2016 07:21 AM, Eric Gallager wrote:
> >> The libdecnumber, libgcc, and libobjc subdirectories are missing TAGS
> >> targets in their Makefiles. The attached patch causes them to be
> >> skipped when running `make tags`.
> >>
> >> ChangeLog entry:
> >>
> >> 2016-10-06  Eric Gallager  
> >>
> >>  * Makefile.def: Mark libdecnumber, libgcc, and libobjc as missing
> >>  TAGS target.
> >>  * Makefile.in: Regenerate.
> >>
> > OK.  Please install.
> >
> > Thanks,
> > Jeff
> >
>
>
> I'm still waiting to hear back from  about my request
> for copyright assignment, which I'll need to get sorted out before I
> can start committing stuff (like this patch).
>
> Thanks,
> Eric

Update: In the intervening years, I got my copyright assignment filed
and have recently become able to commit again; is your old approval
from 2016 still valid, Jeff, or do I need a re-approval?
Ref: https://gcc.gnu.org/legacy-ml/gcc-patches/2016-10/msg00370.html
Thanks,
Eric

Re: [PATCH] libiberty: prevent buffer overflow when decoding user input

[Eric Gallager via Gcc-patches]

On Tue, Oct 5, 2021 at 1:28 PM Luís Ferreira  wrote:
>
> On Tue, 2021-10-05 at 09:00 -0600, Jeff Law wrote:
> >
> >
> > On 10/4/2021 10:52 AM, Luís Ferreira wrote:
> > > On Thu, 2021-09-23 at 09:50 -0600, Jeff Law wrote:
> > > >
> > > > On 9/23/2021 4:16 AM, ibuclaw--- via Gcc-patches wrote:
> > > > > > On 22/09/2021 03:10 Luís Ferreira 
> > > > > > wrote:
> > > > > >
> > > > > >
> > > > > > Currently a stack/heap overflow may happen if a crafted
> > > > > > mangle is
> > > > > > maliciously used to cause denial of service, such as
> > > > > > intentional
> > > > > > crashes
> > > > > > by accessing a reserved memory space.
> > > > > >
> > > > > Hi,
> > > > >
> > > > > Thanks for this.  Is there a test that could trigger this code
> > > > > path?
> > > > I don't think Luis has commit privs, so I went ahead and
> > > > committed
> > > > this
> > > > patch.
> > > >
> > > > Yea, a testcase would be great.
> > > >
> > > > Jeff
> > > >
> > > Does the test suite runned against address sanitization? if yes, I
> > > can
> > > submit a patch to make this fail, otherwise it is hard to trigger a
> > > consistent crash for this issue.
> > Unfortunately, no it doesn't run with sanitization.  If it's too
> > painful
> > to create a test, don't worry about it.  It happens from time to
> > time.
> >
> > jeff
>
> I would like to add address sanitization if I knew how GCC autotools
> work but I think this is a better fit when I invest some time
> implementing something to OSS fuzz and build some infrastructure for
> fuzzing parts of the GCC.
>

I can help with the autotools part if you can say how precisely you'd
like to use them to add address sanitization. And as for the OSS
fuzz part, I think someone tried setting up auto-fuzzing for it once,
but the main bottleneck was getting the bug reports that it generated
properly triaged, so if you could make sure the bug-submitting portion
of the process is properly streamlined, that'd probably go a long way
towards helping it be useful.

> --
> Sincerely,
> Luís Ferreira @ lsferreira.net
>

Re: [PATCH] restore ancient -Waddress for weak symbols [PR33925]

[Eric Gallager via Gcc-patches]

On Mon, Oct 4, 2021 at 2:43 PM Martin Sebor via Gcc-patches
 wrote:
>
> While resolving the recent -Waddress enhancement request (PR
> PR102103) I came across a 2007 problem report about GCC 4 having
> stopped warning for using the address of inline functions in
> equality comparisons with null.  With inline functions being
> commonplace in C++ this seems like an important use case for
> the warning.
>
> The change that resulted in suppressing the warning in these
> cases was introduced inadvertently in a fix for PR 22252.
>
> To restore the warning, the attached patch enhances
> the decl_with_nonnull_addr_p() function to return true also for
> weak symbols for which a definition has been provided.
>
> Tested on x86_64-linux and by comparing the GCC output for new
> test cases to Clang's which diagnoses all but one instance of
> these cases with either -Wtautological-pointer-compare or
> -Wpointer-bool-conversion, depending on context.

Would it make sense to use the same names as clang's flags here, too,
instead of dumping them all under -Waddress? I think the additional
granularity could be helpful for people who only want some warnings,
but not others.

> The one case where Clang doesn't issue a warning but GCC
> with the patch does is for a symbol explicitly declared with
> attribute weak for which a definition has been provided.
> I believe the address of such symbols is necessarily nonnull and
> so issuing the warning is helpful
> (both GCC and Clang fold such comparisons to a constant).
>
> Martin

Re: [PATCH] c: [PR32122] Require pointer types for computed gotos

[Eric Gallager via Gcc-patches]

On Mon, Sep 20, 2021 at 12:15 AM apinski--- via Gcc-patches
 wrote:
>
> From: Andrew Pinski 
>
> So GCC has always accepted non-pointer types in computed gotos but
> that was wrong based on the documentation:
> Any expression of type void * is allowed.
>
> So this fixes the problem by requiring the type to
> be a pointer type.
>
> OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
>
> PR c/32122
>
> gcc/c/ChangeLog:
>
> * c-parser.c (c_parser_statement_after_labels): Pass
> the c_expr instead of the tree to c_finish_goto_ptr.
> * c-typeck.c (c_finish_goto_ptr): Change the second
> argument type to c_expr.
> * c-tree.h (c_finish_goto_ptr): Likewise.
> Error out if the expression was not of a pointer type.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/comp-goto-5.c: New test.
> * gcc.dg/comp-goto-6.c: New test.
> ---
>  gcc/c/c-parser.c   |  2 +-
>  gcc/c/c-tree.h |  2 +-
>  gcc/c/c-typeck.c   | 11 ++-
>  gcc/testsuite/gcc.dg/comp-goto-5.c | 11 +++
>  gcc/testsuite/gcc.dg/comp-goto-6.c |  6 ++
>  5 files changed, 29 insertions(+), 3 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/comp-goto-5.c
>  create mode 100644 gcc/testsuite/gcc.dg/comp-goto-6.c
>
> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> index fb1399e300d..bcd8a05489f 100644
> --- a/gcc/c/c-parser.c
> +++ b/gcc/c/c-parser.c
> @@ -6141,7 +6141,7 @@ c_parser_statement_after_labels (c_parser *parser, bool 
> *if_p,
>   c_parser_consume_token (parser);
>   val = c_parser_expression (parser);
>   val = convert_lvalue_to_rvalue (loc, val, false, true);
> - stmt = c_finish_goto_ptr (loc, val.value);
> + stmt = c_finish_goto_ptr (loc, val);
> }
>   else
> c_parser_error (parser, "expected identifier or %<*%>");
> diff --git a/gcc/c/c-tree.h b/gcc/c/c-tree.h
> index d50d0cb7f2d..a046c6b0926 100644
> --- a/gcc/c/c-tree.h
> +++ b/gcc/c/c-tree.h
> @@ -746,7 +746,7 @@ extern tree c_finish_expr_stmt (location_t, tree);
>  extern tree c_finish_return (location_t, tree, tree);
>  extern tree c_finish_bc_stmt (location_t, tree, bool);
>  extern tree c_finish_goto_label (location_t, tree);
> -extern tree c_finish_goto_ptr (location_t, tree);
> +extern tree c_finish_goto_ptr (location_t, c_expr val);
>  extern tree c_expr_to_decl (tree, bool *, bool *);
>  extern tree c_finish_omp_construct (location_t, enum tree_code, tree, tree);
>  extern tree c_finish_oacc_data (location_t, tree, tree);
> diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
> index 49d1bb067a0..b472e448011 100644
> --- a/gcc/c/c-typeck.c
> +++ b/gcc/c/c-typeck.c
> @@ -10783,10 +10783,19 @@ c_finish_goto_label (location_t loc, tree label)
> the GOTO.  */
>
>  tree
> -c_finish_goto_ptr (location_t loc, tree expr)
> +c_finish_goto_ptr (location_t loc, c_expr val)
>  {
> +  tree expr = val.value;
>tree t;
>pedwarn (loc, OPT_Wpedantic, "ISO C forbids %");
> +  if (expr != error_mark_node
> +  && !POINTER_TYPE_P (TREE_TYPE (expr))
> +  && !null_pointer_constant_p (expr))
> +{
> +  error_at (val.get_location (),
> +   "computed goto must be pointer type");
> +  expr = build_zero_cst (ptr_type_node);
> +}
>expr = c_fully_fold (expr, false, NULL);
>expr = convert (ptr_type_node, expr);
>t = build1 (GOTO_EXPR, void_type_node, expr);
> diff --git a/gcc/testsuite/gcc.dg/comp-goto-5.c 
> b/gcc/testsuite/gcc.dg/comp-goto-5.c
> new file mode 100644
> index 000..d487729a5d4
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/comp-goto-5.c
> @@ -0,0 +1,11 @@
> +/* PR c/32122 */
> +/* { dg-do compile } */
> +/* { dg-options "" } */
> +
> +enum {a=1};
> +void foo()
> +{
> +  goto *
> +a; /* { dg-error "computed goto must be pointer type" } */
> +}
> +
> diff --git a/gcc/testsuite/gcc.dg/comp-goto-6.c 
> b/gcc/testsuite/gcc.dg/comp-goto-6.c
> new file mode 100644
> index 000..497f6cd76ca
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/comp-goto-6.c
> @@ -0,0 +1,6 @@
> +/* PR c/32122 */
> +/* { dg-do compile } */
> +/* { dg-options "" } */
> +void foo(void *a) { goto *1000; } /* { dg-error "computed goto must be 
> pointer type" } */
> +void foo1(void *a) { goto *a; }
> +
> --
> 2.17.1
>

Maybe add to one of the testcases a test to ensure that the
cast-to-void workaround works successfully?
e.g.
void foo2(void *a) { goto *(void *)1000; } /* { dg-bogus "computed
goto must be pointer type" } */

Re: [PATCH] libgfortran : Use the libtool macro to determine libm availability.

[Eric Gallager via Gcc-patches]

On Fri, Aug 20, 2021 at 3:53 AM Tobias Burnus  wrote:
>
> On 20.08.21 09:34, Richard Biener via Fortran wrote:
>
> > On Thu, Aug 19, 2021 at 10:10 PM Iain Sandoe  wrote:
> >> libm is not needed on Darwin, and should not be added unconditionally
> >> even if that is (mostly) harmless since it is a symlink to libc.
> >>
> >> tested on x86_64, i686-darwin, x86_64-linux,
> >> OK for master?
> > OK.
> > Richard.
>
> Looks also good to me – but for completeness and as background, I also
> want to remark the following.
>
> (At least as I understand it, I did not dig deeper.)
>
> > --- a/libgfortran/configure.ac
> > +++ b/libgfortran/configure.ac
> > ...
> > +AC_CHECK_LIBM
>
> This CHECK_LIBM has a hard-coded list of targets and for some (like
> Darwin) it simply does not set $LIBM.

I thought the proper macro to use was LT_LIB_M ?

>
> >> +++ b/libgfortran/Makefile.am
> >> @@ -42,7 +42,7 @@ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS)
> >>   libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' 
> >> $(srcdir)/libtool-version` \
> >>  $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \
> >>  $(HWCAP_LDFLAGS) \
> >> -   -lm $(extra_ldflags_libgfortran) \
> >> +   $(LIBM) $(extra_ldflags_libgfortran) \
>
> I think usage like this one do not actually link '-lm' as
> gcc/config/darwin.h contains:
>
> #define LINK_SPEC  \
> ...
> %:remove-outfile(-lm) \
>
> However, this spec change comes too early for:
> > --- a/libgfortran/libgfortran.spec.in
> > +++ b/libgfortran/libgfortran.spec.in
> > @@ -5,4 +5,4 @@
> >   #
> >
> >   %rename lib liborig
> > -*lib: @LIBQUADSPEC@ -lm %(libgcc) %(liborig)
> > +*lib: @LIBQUADSPEC@  @LIBM@ %(libgcc) %(liborig)
> NIT: There are two spaces instead of one before @LIBM@.
>
> Thus, it makes sense to the unconditional '-lm' from the .spec file.
>
> Tobias
>
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955

Re: [PATCH] Objective-C: don't require redundant -fno-objc-sjlj-exceptions for the NeXT v2 ABI

[Eric Gallager via Gcc-patches]

On Wed, Jul 28, 2021 at 11:36 PM Matt Jacobson via Gcc-patches
 wrote:
>
> As is, an invocation of GCC with -fnext-runtime -fobjc-abi-version=2 crashes,
> unless target-specific code adds an implicit -fno-objc-sjlj-exceptions (which
> Darwin does).
>
> This patch makes the general case not crash.
>
> I don't have commit access, so if this patch is suitable, I'd need someone 
> else
> to commit it for me.  Thanks.

Is there a bug open for the issue that this fixes? Just wondering for
cross-referencing purposes...

>
> gcc/objc/ChangeLog:
>
> 2021-07-28  Matt Jacobson  
>
> * objc-next-runtime-abi-02.c (objc_next_runtime_abi_02_init): Warn
> about and reset flag_objc_sjlj_exceptions regardless of
> flag_objc_exceptions.
>
>
> gcc/c-family/ChangeLog:
>
> 2021-07-28  Matt Jacobson  
>
> * c-opts.c (c_common_post_options): Default to
> flag_objc_sjlj_exceptions = 1 only when flag_objc_abi < 2.
>
> diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
> index c51d6d34726..2568df67972 100644
> --- a/gcc/c-family/c-opts.c
> +++ b/gcc/c-family/c-opts.c
> @@ -840,9 +840,9 @@ c_common_post_options (const char **pfilename)
>else if (!flag_gnu89_inline && !flag_isoc99)
>  error ("%<-fno-gnu89-inline%> is only supported in GNU99 or C99 mode");
>
> -  /* Default to ObjC sjlj exception handling if NeXT runtime.  */
> +  /* Default to ObjC sjlj exception handling if NeXT if (flag_objc_sjlj_exceptions < 0)
> -flag_objc_sjlj_exceptions = flag_next_runtime;
> +flag_objc_sjlj_exceptions = (flag_next_runtime && flag_objc_abi < 2);
>if (flag_objc_exceptions && !flag_objc_sjlj_exceptions)
>  flag_exceptions = 1;
>
> diff --git a/gcc/objc/objc-next-runtime-abi-02.c 
> b/gcc/objc/objc-next-runtime-abi-02.c
> index 66c13ad0db2..9a0868410a8 100644
> --- a/gcc/objc/objc-next-runtime-abi-02.c
> +++ b/gcc/objc/objc-next-runtime-abi-02.c
> @@ -245,7 +245,7 @@ objc_next_runtime_abi_02_init (objc_runtime_hooks 
> *rthooks)
>  {
>extern_names = ggc_cleared_vec_alloc (SIZEHASHTABLE);
>
> -  if (flag_objc_exceptions && flag_objc_sjlj_exceptions)
> +  if (flag_objc_sjlj_exceptions)
>  {
>inform (UNKNOWN_LOCATION,
>   "%<-fobjc-sjlj-exceptions%> is ignored for "
>

Re: [PATCH] libgcc libiberty: optimize and modernize standard string and memory functions

[Eric Gallager via Gcc-patches]

On Wed, Jun 9, 2021 at 12:10 PM Jeff Law via Gcc-patches
 wrote:
>
>
>
> On 6/3/2021 12:51 PM, Seija K. via Gcc-patches wrote:
> > This patch optimizes and simplifies many of the standard string functions.
> >
> > Since C99, some of the standard string functions have been changed to use
> > the restrict modifier.
> >
> > diff --git a/libgcc/memcmp.c b/libgcc/memcmp.c
> > index 2348afe1d27f7..74195cf6baf13 100644
> > --- a/libgcc/memcmp.c
> > +++ b/libgcc/memcmp.c
> > @@ -7,10 +7,11 @@ memcmp (const void *str1, const void *str2, size_t count)
> > const unsigned char *s1 = str1;
> > const unsigned char *s2 = str2;
> >
> > -  while (count-- > 0)
> > +  while (count--)
> >   {
> > -  if (*s1++ != *s2++)
> > -   return s1[-1] < s2[-1] ? -1 : 1;
> > +  if (*s1 != *s2)
> > +   return *s1 < *s2 ? -1 : 1;
> > +  s1++, s2++;
> >   }
> > return 0;
> >   }
> I don't see the point behind this change and the similar ones in other
> files.  I'd like to see some justification for the change beyond just
> "this looks cleaner to me".
>
>
>
>
>
> > diff --git a/libgcc/memcpy.c b/libgcc/memcpy.c
> > index 58b1e405627aa..616df78fd2969 100644
> > --- a/libgcc/memcpy.c
> > +++ b/libgcc/memcpy.c
> > @@ -2,7 +2,7 @@
> >   #include 
> >
> >   void *
> > -memcpy (void *dest, const void *src, size_t len)
> > +memcpy (void * restrict dest, const void * restrict src, size_t len)
> I would expect prototype fixes like this within libgcc to be reasonably
> safe.
>
> > diff --git a/libiberty/memcpy.c b/libiberty/memcpy.c
> > index 7f67d0bd1f26c..d388ae7f3506b 100644
> > --- a/libiberty/memcpy.c
> > +++ b/libiberty/memcpy.c
> > @@ -19,7 +19,7 @@ Copies @var{length} bytes from memory region
> > @var{in} to region
> >   void bcopy (const void*, void*, size_t);
> >
> >   PTR
> > -memcpy (PTR out, const PTR in, size_t length)
> > +memcpy (PTR restrict out, const PTR restrict in, size_t length)
> It's not entirely clear that using "restrict" is safe because libiberty
> is used by so many other projects which may be building with old
> compilers, non-gcc compilers, etc.
>
> Generally the way to handle this is to use an autoconf check to confirm
> that the tools can handle the feature you want to use and ensure there's
> a fallback when they can't.
>

The macro that autoconf provides for this purpose is AC_C_RESTRICT;
it's documented here:
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/html_node/C-Compiler.html
...and defined here:
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=blob;f=lib/autoconf/c.m4;h=47434c89845e1a3f6b579cdac81aae5f27809daa;hb=HEAD#l2030

> Jeff

Re: [PATCH] c++: Add new warning options for C++ language mismatches

[Eric Gallager via Gcc-patches]

On Wed, May 19, 2021 at 12:33 PM Jonathan Wakely via Gcc-patches
 wrote:
>
> This adds new warning flags, enabled by default: -Wc++11-extensions,
> -Wc++14-extensions, -Wc++17-extensions, and -Wc++20-extensions. The
> names of the flags are copied from Clang, which already has similar
> options.
>
> No new diagnostics are added, but the new OPT_Wxxx variables are used to
> control existing pedwarns about occurences of new C++ constructs in code
> using an old C++ standard dialect. This allows several existing warnings
> that cannot currently be disabled to be controlled by the appropriate
> -Wno-xxx flag. For example, it will now be possible to disable warnings
> about using variadic templates in C++98 code, by using the new
> -Wno-c++11-extensions option. This will allow libstdc++ headers to
> disable those warnings unconditionally by using diagnostic pragmas, so
> that they are not emitted even if -Wsystem-headers is used.
>
> Some of the affected diagnostics are currently only given when
> -Wpedantic is used. Now that we have a more specific warning flag, we
> could consider making them not depend on -Wpedantic, and only on the new
> flag. This patch does not do that, as it intends to make no changes to
> what is accepted/rejected by default. The only effect should be that
> the new option is shown when -fdiagnostics-show-option is active, and
> that some warnings can be disabled by using the new flags (and for the
> warnings that previously only dependend on -Wpedantic, it will now be
> possible to disable just those warnings while still using -Wpedantic for
> its other benefits).
>
> A new helper function, warn_about_dialect_p, is introduced to avoid the
> repetition of `if (cxx_dialect < cxxNN && warn_cxxNN_extensions)`
> everywhere.
>
> gcc/c-family/ChangeLog:
>
> * c.opt (Wc++11-extensions, Wc++14-extensions)
> (Wc++17-extensions, Wc++20-extensions): New options.
>
> gcc/cp/ChangeLog:
>
> * call.c (maybe_warn_array_conv): Use new function and option.
> * cp-tree.h (warn_about_dialect_p): Declare new function.
> * error.c (maybe_warn_cpp0x): Use new function and options.
> (warn_about_dialect_p): Define new function.
> * parser.c (cp_parser_unqualified_id): Use new function and
> option.
> (cp_parser_pseudo_destructor_name): Likewise.
> (cp_parser_lambda_introducer): Likewise.
> (cp_parser_lambda_declarator_opt): Likewise.
> (cp_parser_init_statement): Likewise.
> (cp_parser_decomposition_declaration): Likewise.
> (cp_parser_function_specifier_opt): Likewise.
> (cp_parser_static_assert): Likewise.
> (cp_parser_namespace_definition): Likewise.
> (cp_parser_initializer_list): Likewise.
> (cp_parser_member_declaration): Likewise.
> * pt.c (check_template_variable): Likewise.
>
> Tested x86_64-linux. OK for trunk?
>
>

Thank you for doing this! One thing I'm wondering about, is that I'm
pretty sure clang also allows at least some of these to be used with
plain C as well, for example for things like the old use of "auto" in
C conflicting with the newer C++11 meaning of "auto". Would it be
possible to do likewise for GCC as well? Just an idea.
Thanks,
Eric Gallager

Re: [PATCH v2] C++ : Add the -stdlib= option.

[Eric Gallager via Gcc-patches]

Hi Iain, could you add a note about this change to the
gcc-11/changes.html page? There are probably some people who would be
interested in this who could use a note about it. Thanks

On Tue, Dec 22, 2020 at 3:53 PM Jason Merrill via Gcc-patches
 wrote:
>
> On 12/22/20 3:39 PM, Iain Sandoe wrote:
> > Hi Jason,
> >
> > Jason Merrill  wrote:
> >
> >> On 11/11/20 3:58 PM, Iain Sandoe wrote:
> >
> >>> This option allows the user to specify alternate C++ runtime libraries,
> >>> for example when a platform uses libc++ as the installed C++ runtime.
> >>> It is the same spelling as a clang option that allows that to use 
> >>> libstdc++.
> >>> I have had this patch for some time now (more than a year) on Darwin
> >>> branches.
> >>>
> >
> >>> +  /* Which standard library to link.
> >>> + 1 = libstdc++
> >>> + 2 = libc++.  */
> >>> +  int which_library = 1;
> >>
> >> Even if this variable is an int, let's introduce an enum for comparing it 
> >> to specific values.
> >
> > done - it is also noted that it must track the enum in the opt file.
> >
> >>> @@ -264,6 +293,8 @@ lang_specific_driver (struct cl_decoded_option 
> >>> **in_decoded_options,
> >>>   /* Add one for shared_libgcc or extra static library.  */
> >>>   num_args = argc + added + need_math + (library > 0) * 4 + 1;
> >>> +  if (which_library > 1 && LIBCXXABI != NULL)
> >>> +num_args += 4;
> >>
> >> Why does libc++ need more args than libstdc++?  Please add a comment.
> >
> > done (JFTR, it’s because libc++ doesn’t include the abi library for most 
> > platforms, so that also has to be
> > appended to the link line).
> >
> >>> +#ifdef GPLUSPLUS_LIBCXX_INCLUDE_DIR
> >>> +/* Pick up libc++ include files, if we have -stdlib=libc++.  */
> >>> +{ GPLUSPLUS_LIBCXX_INCLUDE_DIR, "G++", 2, 1,
> >>
> >> If you're going to give cplusplus a non-boolean value, the comment in 
> >> cppdefault.h needs to reflect that.
> >
> > done.
> >
> > (re-)tested on x86_64-darwin{11,16,17,19, 20} with the installed libc++ and 
> > x86_64-linux-gnu with an
> > LLVM-9 build.  Bootstrapped and smoke-tested for libc++ (regular testing 
> > for libstdc++).
> >
> > OK for master now?
>
> OK.
>
> > thanks
> > Iain
> >
> >  revised patch
> >
> >
> > This option allows the user to specifiy alternate C++ runtime libraries,
> > for example when a platform uses libc++ as the installed C++ runtime.
> >
> > We introduce the command line option: -stdlib= which is the user-facing
> > mechanism to select the C++ runtime to be used when compiling and linking
> > code.  This is the same option spelling as that used by clang to allow the
> > use of libstdc++.
> >
> > The availability (and thus function) of the option are a configure-time
> > choice using the configuration control:
> > --with-gxx-libcxx-include-dir=
> >
> > Specification of the path for the libc++ headers, enables the -stdlib=
> > option (using the path as given), default values are set when the path
> > is unconfigured.
> >
> > If --with-gxx-libcxx-include-dir is given together with --with-sysroot=,
> > then we test to see if the include path starts with the sysroot and, if so,
> > record the sysroot-relative component as the local path.  At runtime, we
> > prepend the sysroot that is actually active.
> >
> > At link time, we use the C++ runtime in force and (if that is libc++) also
> > append the libc++abi ABI library. As for other cases, if a target sets the
> > name pointer for the ABI library to NULL the G++ driver will omit it from
> > the link line.
> >
> > gcc/ChangeLog:
> >
> >   * configure.ac: Add gxx-libcxx-include-dir handled
> >   in the same way as the regular cxx header directory.
> >   * Makefile.in: Regenerated.
> >   * config.in: Likewise.
> >   * configure: Likewise.
> >   * cppdefault.c: Pick up libc++ headers if the option
> >   is enabled.
> >   * cppdefault.h (struct default_include): Amend comments
> >   to reflect the extended use of the cplusplus field.
> >   * incpath.c (add_standard_paths): Allow for multiple
> >   c++ header include path variants.
> >   * doc/invoke.texi: Document the -stdlib= option.
> >
> > gcc/c-family/ChangeLog:
> >
> >   * c.opt: Add -stdlib= option and enumerations for
> >   libstdc++ and libc++.
> >
> > gcc/cp/ChangeLog:
> >
> >   * g++spec.c (LIBCXX, LIBCXX_PROFILE, LIBCXX_STATIC): New.
> >   (LIBCXXABI, LIBCXXABI_PROFILE, LIBCXXABI_STATIC): New.
> >   (enum stdcxxlib_kind): New.
> >   (lang_specific_driver): Allow selection amongst multiple
> >   c++ runtime libraries.
> > ---
> >   gcc/Makefile.in |  6 
> >   gcc/c-family/c.opt  | 14 +
> >   gcc/config.in   |  6 
> >   gcc/configure   | 57 --
> >   gcc/configure.ac| 44 +++
> >   gcc/cp/g++spec.c| 74 -
> >   gcc/cppdefault.c|  5 +++
> >   gcc/cppdefault.h|  7 -
> >   

Re: [PATCH] adjust "partly out of bounds" warning (PR 98503)

[Eric Gallager via Gcc-patches]

On Thu, Jan 28, 2021 at 6:04 PM Martin Sebor via Gcc-patches
 wrote:
>
> The GCC 11 -Warray-bounds enhancement to diagnose accesses whose
> leading offset is in bounds but whose trailing offset is not has
> been causing some confusion.  When the warning is issued for
> an access to an in-bounds member via a pointer to a struct that's
> larger than the pointed-to object, phrasing this strictly invalid
> access in terms of array subscripts can be misleading, especially
> when the source code doesn't involve any arrays or indexing.
>
> Since the problem boils down to an aliasing violation much more
> so than an actual out-of-bounds access, the attached patch adjusts
> the code to issue a -Wstrict-aliasing warning in these cases instead
> of -Warray-bounds.  In addition, since the aliasing assumptions in
> GCC can be disabled by -fno-strict-aliasing, the patch also makes
> these instances of the warning conditional on -fstrict-aliasing
> being in effect.
>
> Martin

-Wstrict-aliasing is a warning with numerical levels; can you clarify
which of them this is active at?
(also I have always found it confusing how -Wstrict-aliasing's
numerical levels are in reverse order from most other warnings with
numerical levels; i.e., how higher numbers supposedly mean fewer
warnings for it (according to documentation) rather than more, as is
the case with most other warnings with numerical levels)

Re: [committed] wwwdocs: Move cilkplus to Inactive branches

[Eric Gallager via Gcc-patches]

On Sun, Dec 27, 2020 at 6:55 PM Gerald Pfeifer  wrote:

> On Sun, 27 Dec 2020, Eric Gallager wrote:
> > If it's now inactive, maybe also reword the description to change tense
> > from present to past?
> > i.e.:
>
> Yes...
>
> > cilkplus
> > This branch was for the development of the now-obsolete Cilk Plus
> > language extension support for the GCC and G++ compilers.  This branch
> > was maintained by mailto:balaji.v.i...@intel.com;>Balaji V.
> > Iyer.
> > When patches to this branch were still being accepted, they were required
> > to be prefixed with [cilkplus] wwwdocs: in the subject,
> which
> > can be used as a search term for people looking in the mail archives for
> > more information about this branch.
>
> ...though in the spirit of keeping things here as brief as possible,
> how about "Patches were required to ..." and similarly trying to shorten
> the rest of that paragraph?
>
> On Sun, 27 Dec 2020, Eric Gallager wrote:
> > Also maybe remove the email address, since it bounces now
>
> Agreed.
>
> Do you want to go ahead and commit those changes? Help with the
> web pages is much appreciated, and it's quite simple actually
> (cf. https://gcc.gnu.org/about.html and I'm happy to help).
>
>
I haven't made a commit to the wwwdocs repo yet, and the last time I
committed
to the main gcc sources repo it was before the transition to git, and I did
it from a
different computer, and I'm not sure if I transferred my ssh keys to my new
computer properly; I might need some help with the setup there... it might
be
faster to just commit the changes yourself.


> Thanks,
> Gerald
>

Re: [committed] wwwdocs: Move cilkplus to Inactive branches

[Eric Gallager via Gcc-patches]

On Sun, Dec 27, 2020 at 1:59 PM Eric Gallager  wrote:

> On Sun, Dec 27, 2020 at 1:50 PM Gerald Pfeifer  wrote:
>
>> Cilk Plus has been deprecated more than two years ago and not seen
>> development on the GCC side for a while, too.
>>
>> The certificate for www.cilkplus.org expired four weeks ago, so
>> remove our link there as we move the Cilk Plus entry to the section
>> of Inactive Development branches.
>> ---
>>  htdocs/git.html | 15 +++
>>  1 file changed, 7 insertions(+), 8 deletions(-)
>>
>> diff --git a/htdocs/git.html b/htdocs/git.html
>> index 305d0c93..41bbe35b 100644
>> --- a/htdocs/git.html
>> +++ b/htdocs/git.html
>> @@ -442,14 +442,6 @@ in Git.
>>This branch is for development of a C++ modules system.  It is
>>maintained by mailto:nat...@acm.org;>Nathan
>> Sidwell.
>>
>> -  cilkplus
>> -  This branch is for the development of
>> -https://www.cilkplus.org;>Cilk Plus language extension
>> support
>> -on GCC and G++ compilers.  This branch is maintained by
>> -mailto:balaji.v.i...@intel.com;>Balaji V. Iyer.
>> -Patches to this branch must be prefixed with [cilkplus]
>> wwwdocs: in the
>> -subject line.  It is also highly encouraged to CC the
>> maintainer.
>> -
>>fortran-dev
>>This branch is for disruptive changes to the Fortran front end,
>>  especially for OOP development and
>> @@ -822,6 +814,13 @@ merged.
>>the code size optimization of GCC with code factoring methods (code
>>motion and merging algorithms).  It is no longer maintained.
>>
>> +  cilkplus
>> +  This branch is for the development of Cilk Plus language extension
>> +  support on GCC and G++ compilers.  This branch is maintained by
>> +  mailto:balaji.v.i...@intel.com;>Balaji V. Iyer.
>> +  Patches to this branch must be prefixed with [cilkplus]
>> wwwdocs: in
>> +  the subject.  It is also highly encouraged to CC the maintainer.
>> +
>>
>
> If it's now inactive, maybe also reword the description to change tense
> from present to past?
> i.e.:
>
> cilkplus
> This branch was for the development of the now-obsolete Cilk Plus
> language extension support for the GCC and G++ compilers.  This branch
> was maintained by mailto:balaji.v.i...@intel.com;>Balaji V.
> Iyer.
> When patches to this branch were still being accepted, they were required
> to be prefixed with [cilkplus] wwwdocs: in the subject, which
> can be used as a search term for people looking in the mail archives for
> more information about this branch.
>

Also maybe remove the email address, since it bounces now


>
>
>>compile-server-branch
>>This branch was aimed at improving compile speed by caching work
>>done between compilations.  The work saved is mainly related to header
>> --
>> 2.29.2
>>
>

Re: [committed] wwwdocs: Move cilkplus to Inactive branches

[Eric Gallager via Gcc-patches]

On Sun, Dec 27, 2020 at 1:50 PM Gerald Pfeifer  wrote:

> Cilk Plus has been deprecated more than two years ago and not seen
> development on the GCC side for a while, too.
>
> The certificate for www.cilkplus.org expired four weeks ago, so
> remove our link there as we move the Cilk Plus entry to the section
> of Inactive Development branches.
> ---
>  htdocs/git.html | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/htdocs/git.html b/htdocs/git.html
> index 305d0c93..41bbe35b 100644
> --- a/htdocs/git.html
> +++ b/htdocs/git.html
> @@ -442,14 +442,6 @@ in Git.
>This branch is for development of a C++ modules system.  It is
>maintained by mailto:nat...@acm.org;>Nathan
> Sidwell.
>
> -  cilkplus
> -  This branch is for the development of
> -https://www.cilkplus.org;>Cilk Plus language extension
> support
> -on GCC and G++ compilers.  This branch is maintained by
> -mailto:balaji.v.i...@intel.com;>Balaji V. Iyer.
> -Patches to this branch must be prefixed with [cilkplus]
> wwwdocs: in the
> -subject line.  It is also highly encouraged to CC the maintainer.
> -
>fortran-dev
>This branch is for disruptive changes to the Fortran front end,
>  especially for OOP development and
> @@ -822,6 +814,13 @@ merged.
>the code size optimization of GCC with code factoring methods (code
>motion and merging algorithms).  It is no longer maintained.
>
> +  cilkplus
> +  This branch is for the development of Cilk Plus language extension
> +  support on GCC and G++ compilers.  This branch is maintained by
> +  mailto:balaji.v.i...@intel.com;>Balaji V. Iyer.
> +  Patches to this branch must be prefixed with [cilkplus]
> wwwdocs: in
> +  the subject.  It is also highly encouraged to CC the maintainer.
> +
>

If it's now inactive, maybe also reword the description to change tense
from present to past?
i.e.:

cilkplus
This branch was for the development of the now-obsolete Cilk Plus
language extension support for the GCC and G++ compilers.  This branch
was maintained by mailto:balaji.v.i...@intel.com;>Balaji V.
Iyer.
When patches to this branch were still being accepted, they were required
to be prefixed with [cilkplus] wwwdocs: in the subject, which
can be used as a search term for people looking in the mail archives for
more information about this branch.


>compile-server-branch
>This branch was aimed at improving compile speed by caching work
>done between compilations.  The work saved is mainly related to header
> --
> 2.29.2
>

Re: [PATCH 1/8 v4] Dead-field warning in structs at LTO-time

[Eric Gallager via Gcc-patches]

On Fri, Dec 4, 2020 at 4:58 AM Erick Ochoa <
erick.oc...@theobroma-systems.com> wrote:

>
> This commit includes the following components:
>
>Type-based escape analysis to determine structs that can be modified at
>link-time.
>Field access analysis to determine which fields are never read.
>
> The type-based escape analysis provides a list of types, that are not
> visible outside of the current linking unit (e.g. parameter types of
> external
> functions).
>
> The field access analyses non-escaping structs for fields that
> are not used in the linking unit and thus can be removed.
>
> 2020-11-04  Erick Ochoa  
>
>  * Makefile.in: Add file to list of new sources.
>  * common.opt: Add new flags.
>  * ipa-type-escape-analysis.c: New file.
> ---
>   gcc/Makefile.in|1 +
>   gcc/common.opt |8 +
>   gcc/ipa-type-escape-analysis.c | 3428 
>   gcc/ipa-type-escape-analysis.h | 1152 +++
>   gcc/passes.def |1 +
>   gcc/timevar.def|1 +
>   gcc/tree-pass.h|2 +
>   7 files changed, 4593 insertions(+)
>   create mode 100644 gcc/ipa-type-escape-analysis.c
>   create mode 100644 gcc/ipa-type-escape-analysis.h
>
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 978a08f7b04..8b18c9217a2 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -1415,6 +1415,7 @@ OBJS = \
> incpath.o \
> init-regs.o \
> internal-fn.o \
> +   ipa-type-escape-analysis.o \
> ipa-cp.o \
> ipa-sra.o \
> ipa-devirt.o \
> diff --git a/gcc/common.opt b/gcc/common.opt
> index d4cbb2f86a5..85351738a29 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -3460,4 +3460,12 @@ fipa-ra
>   Common Report Var(flag_ipa_ra) Optimization
>   Use caller save register across calls if possible.
>   +fipa-type-escape-analysis
> +Common Report Var(flag_ipa_type_escape_analysis) Optimization
> +This flag is only used for debugging the type escape analysis
> +
> +Wdfa
> +Common Var(warn_dfa) Init(1) Warning
> +Warn about dead fields at link time.
> +
>

I don't really like the name "-Wdfa" very much; could you maybe come up
with a longer and more descriptive name instead? Say, "-Wunused-field" or
"-Wunused-private-field" depending on the kind of field:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92801


>   ; This comment is to ensure we retain the blank line above.
> diff --git a/gcc/ipa-type-escape-analysis.c
> b/gcc/ipa-type-escape-analysis.c
> new file mode 100644
> index 000..32c8bf997fb
> --- /dev/null
> +++ b/gcc/ipa-type-escape-analysis.c
> @@ -0,0 +1,3428 @@
> +/* IPA Type Escape Analysis and Dead Field Elimination
> +   Copyright (C) 2019-2020 Free Software Foundation, Inc.
> +
> +  Contributed by Erick Ochoa 
> +
> +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
> +.  */
> +
> +/* Interprocedural dead field analysis (IPA-DFA)
> +
> +   The goal of this analysis is to
> +
> +   1) discover RECORD_TYPEs which do not escape the current linking unit.
> +
> +   2) discover fields in RECORD_TYPEs that are never read.
> +
> +   3) merge the results from 1 and 2 to determine which fields are not
> needed.
> +
> +   The algorithm basically consists of the following stages:
> +
> +   1) Partition all TYPE_P trees into two sets: those trees which reach a
> +   tree of RECORD_TYPE.
> +
> +   2.a) Analyze callsites to determine if arguments and return types are
> +   escaping.
> +   2.b) Analyze casts to determine if it would be safe to mark a field
> as dead.
> +   2.c) Analyze for constructors and static initialization and mark this
> as
> +   TYPE_P trees as unable to be modified
> +   2.d) Analyze if FIELD_DECL are accessed via pointer arithmetic and mark
> +   FIELD_DECLs before as unable to be modified.
> +   2.e) Analyze if an address of a FIELD_DECL is taken and mark the whole
> +   RECORD_TYPE as unable to be modified.
> +   2.f) Propagate this information to nested TYPE_P trees.
> +   2.g) Propagate this information across different TYPE_P trees that
> represent
> +   equivalent TYPE_P types.
> +
> +   3.a) Analyze FIELD_DECL to determine whether they are read,
> +   written or neither.
> +   3.b) Unify this information across different RECORD_TYPE trees that
> +   represent 

Re: [RFC c-common PATCH] PR c++/40752 - useless -Wconversion with short +=. [wwwdocs]

[Eric Gallager via Gcc-patches]

On 5/10/20, Eric Gallager  wrote:
> On 1/10/20, Jason Merrill  wrote:
>> Back in 2009 Manuel sent a patch to avoid useless -Wconversion warnings
>> on compound assignment of types that get promoted to int:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2009-08/msg00582.html
>>
>> Joseph argued that those warnings are sometimes useful, and that they
>> should be controlled by a separate flag.  So this patch introduces
>> -Warith-conversion, which is off by default in this patch.
>>
>> Joseph, is that default OK with you?  If not, can you explain your
>> reasoning more about why the warnings are desirable?  It seems to me
>> that even in cases where you don't know the ranges involved, it's wrong
>> for e.g. 'mychar += 1' to warn when 'myint += 1' doesn't.  In both
>> cases, the addition might overflow the range of the target type, but
>> that isn't about the conversion; the result is the same as if the
>> operation had been done in the operand/target type rather than the
>> promoted type.
>>
>> The change to cp/typeck.c is a placeholder to use if the default setting
>> changes; even if we end up warning by default for mychar = mychar + 1, I
>> really don't want to warn about mychar += 1.
>>
>> sign.diff is a prerequisite tidying that moves the warnings from
>> unsafe_conversion_p back into conversion_warning with the others.
>>
>> rshift.diff restores the short_shift code to the C++ front end so that C
>> and C++ give the same warnings with -Warith-conversion.
>>
>> Tested x86_64-pc-linux-gnu.  Comments?
>>
>
> Hi Jason, thanks for this new flag. Now that GCC 10 has been released
> I was checking the release notes to review everything new in GCC 10,
> and I didn't see any mention of -Warith-conversion on it. Could you
> add a quick note about -Warith-conversion to changes.html please?
>
> Thanks,
> Eric
>

Something just like "Some warnings that -Wconversion previously issued
now also require -Warith-conversion" or something would be fine.

Re: [RFC c-common PATCH] PR c++/40752 - useless -Wconversion with short +=.

[Eric Gallager via Gcc-patches]

On 1/10/20, Jason Merrill  wrote:
> Back in 2009 Manuel sent a patch to avoid useless -Wconversion warnings
> on compound assignment of types that get promoted to int:
>
> https://gcc.gnu.org/ml/gcc-patches/2009-08/msg00582.html
>
> Joseph argued that those warnings are sometimes useful, and that they
> should be controlled by a separate flag.  So this patch introduces
> -Warith-conversion, which is off by default in this patch.
>
> Joseph, is that default OK with you?  If not, can you explain your
> reasoning more about why the warnings are desirable?  It seems to me
> that even in cases where you don't know the ranges involved, it's wrong
> for e.g. 'mychar += 1' to warn when 'myint += 1' doesn't.  In both
> cases, the addition might overflow the range of the target type, but
> that isn't about the conversion; the result is the same as if the
> operation had been done in the operand/target type rather than the
> promoted type.
>
> The change to cp/typeck.c is a placeholder to use if the default setting
> changes; even if we end up warning by default for mychar = mychar + 1, I
> really don't want to warn about mychar += 1.
>
> sign.diff is a prerequisite tidying that moves the warnings from
> unsafe_conversion_p back into conversion_warning with the others.
>
> rshift.diff restores the short_shift code to the C++ front end so that C
> and C++ give the same warnings with -Warith-conversion.
>
> Tested x86_64-pc-linux-gnu.  Comments?
>

Hi Jason, thanks for this new flag. Now that GCC 10 has been released
I was checking the release notes to review everything new in GCC 10,
and I didn't see any mention of -Warith-conversion on it. Could you
add a quick note about -Warith-conversion to changes.html please?

Thanks,
Eric