[0/8] Stop using obsoleted egrep/fgrep

  egrep and fgrep have been deprecated for a long time, and the next grep
release will emit a warning if egrep or fgrep is invoked:

https://git.savannah.gnu.org/cgit/grep.git/commit/?id=a951562

To prevent us from a lot of these warnings in the future, we should stop
using egrep and fgrep.  These patches will remove most of the use of
egrep or fgrep from GCC building system.  The remaining:

* The configure scripts generated by autoconf-2.69 will still refer to
  "egrep", but they will try "grep -E" first and only try egrep when
  "grep -E" is not available.
* libgo: Left for Ian because I'm not familiar with it.
* maintainer-scripts/update_web_docs_libstdcxx_git: Left for Jonathan
  because I don't think other people will invoke it.
* libffi: Already submitted https://github.com/libffi/libffi/pull/720.
* contrib/gen_autofdo_event.py and gcc/config/i386/gcc-auto-profile:
  I'll make a patch later (now download.01.org seems down so I can't
  test or regenerate gcc-auto-profile) porting gen_autofdo_event.py to
  Python 3.

Xi Ruoyao (8):
  config: use grep -E instead of egrep
  fixincludes: use grep -E/-F instead of egrep/fgrep
  libstdc++: use grep -E instead of egrep in scripts
  libbacktrace: use grep -F instead of fgrep
  intl: stop using fgrep for exgettext
  fortran: use grep -F instead of fgrep
  testsuite: use grep -E instead of egrep
  contrib: use grep -E instead of egrep

 config.rpath                            |  8 ++++----
 config/lib-ld.m4                        |  4 ++--
 configure                               |  4 ++--
 configure.ac                            |  4 ++--
 contrib/check_GNU_style.sh              | 10 +++++-----
 contrib/test_summary                    |  2 +-
 contrib/warn_summary                    |  2 +-
 fixincludes/fixinc.in                   |  2 +-
 fixincludes/fixincl.x                   | 10 +++++-----
 fixincludes/genfixes                    |  2 +-
 fixincludes/inclhack.def                |  6 +++---
 gcc/configure                           |  8 ++++----
 gcc/fortran/Make-lang.in                |  2 +-
 gcc/po/exgettext                        |  2 +-
 gcc/testsuite/ada/acats/run_all.sh      |  2 +-
 gcc/testsuite/go.test/go-test.exp       |  2 +-
 intl/configure                          |  4 ++--
 libbacktrace/configure                  |  2 +-
 libbacktrace/configure.ac               |  2 +-
 libcpp/configure                        |  4 ++--
 libgcc/configure                        |  2 +-
 libstdc++-v3/configure                  |  4 ++--
 libstdc++-v3/scripts/extract_symvers.in |  4 ++--
 libstdc++-v3/scripts/run_doxygen        |  4 ++--
 24 files changed, 48 insertions(+), 48 deletions(-)
  

Hi Xi,

> egrep and fgrep have been deprecated for a long time, and the next grep
> release will emit a warning if egrep or fgrep is invoked:
>
> https://git.savannah.gnu.org/cgit/grep.git/commit/?id=a951562
>
> To prevent us from a lot of these warnings in the future, we should stop
> using egrep and fgrep.  These patches will remove most of the use of
> egrep or fgrep from GCC building system.  The remaining:

please remember that there's a world outside of GNU grep: e.g. Solaris
/bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
unconditionally replacing egrep with grep -E in several places is likely
to break at least the Solaris build.

Please see the autoconf manual for details.  I suspect you'll have to
rework the patch set to use AC_PROG_EGREP and $EGREP instead.

	Rainer
  

On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:

> please remember that there's a world outside of GNU grep: e.g. Solaris
> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
> unconditionally replacing egrep with grep -E in several places is
> likely
> to break at least the Solaris build.
> 
> Please see the autoconf manual for details.  I suspect you'll have to
> rework the patch set to use AC_PROG_EGREP and $EGREP instead.

Thanks for the advice.  I'll rework on it.

Is there some way to access a Solaris and do some test?
  

Hi Xi,

> On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
>
>> please remember that there's a world outside of GNU grep: e.g. Solaris
>> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
>> unconditionally replacing egrep with grep -E in several places is
>> likely
>> to break at least the Solaris build.
>> 
>> Please see the autoconf manual for details.  I suspect you'll have to
>> rework the patch set to use AC_PROG_EGREP and $EGREP instead.
>
> Thanks for the advice.  I'll rework on it.
>
> Is there some way to access a Solaris and do some test?

Sure: there's a Solaris 11.3/SPARC system (gcc211)in the GCC compile
farm (https://gcc.gnu.org/wiki/CompileFarm).

Unfortunately, there's neither Solaris 11.4 or Solaris/x86 at the
moment, but those don't differ in this regard.

	Rainer
  

On 2022-06-24, Rainer Orth wrote:
>Hi Xi,
>
>> On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
>>
>>> please remember that there's a world outside of GNU grep: e.g. Solaris
>>> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
>>> unconditionally replacing egrep with grep -E in several places is
>>> likely
>>> to break at least the Solaris build.
>>>
>>> Please see the autoconf manual for details.  I suspect you'll have to
>>> rework the patch set to use AC_PROG_EGREP and $EGREP instead.
>>
>> Thanks for the advice.  I'll rework on it.
>>
>> Is there some way to access a Solaris and do some test?
>
>Sure: there's a Solaris 11.3/SPARC system (gcc211)in the GCC compile
>farm (https://gcc.gnu.org/wiki/CompileFarm).
>
>Unfortunately, there's neither Solaris 11.4 or Solaris/x86 at the
>moment, but those don't differ in this regard.
>
>	Rainer

FWIW: glibc recently got the grep -E change and the solution is to use
plain grep -E, without $EGREP things.
Isn't setting PATH a good workaround if Solaris has the problem?

https://sourceware.org/pipermail/libc-alpha/2022-June/139420.html

> Yes, it is safe nowadays to use 'grep -E' instead of egrep. The only 
> vendor-supported platform I know of where '/usr/bin/grep -E' does not 
> work is Solaris 10 (end-of-life January 2024), and that's easily fixed 
> by prepending /usr/xpg4/bin to PATH.
  

On Fri, Jun 24, 2022 at 1:27 AM Fangrui Song via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> On 2022-06-24, Rainer Orth wrote:
> >Hi Xi,
> >
> >> On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
> >>
> >>> please remember that there's a world outside of GNU grep: e.g. Solaris
> >>> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
> >>> unconditionally replacing egrep with grep -E in several places is
> >>> likely
> >>> to break at least the Solaris build.
> >>>
> >>> Please see the autoconf manual for details.  I suspect you'll have to
> >>> rework the patch set to use AC_PROG_EGREP and $EGREP instead.
> >>
> >> Thanks for the advice.  I'll rework on it.
> >>
> >> Is there some way to access a Solaris and do some test?
> >
> >Sure: there's a Solaris 11.3/SPARC system (gcc211)in the GCC compile
> >farm (https://gcc.gnu.org/wiki/CompileFarm).
> >
> >Unfortunately, there's neither Solaris 11.4 or Solaris/x86 at the
> >moment, but those don't differ in this regard.
> >
> >       Rainer
>
> FWIW: glibc recently got the grep -E change and the solution is to use
> plain grep -E, without $EGREP things.
> Isn't setting PATH a good workaround if Solaris has the problem?

glibc is a different story partly but I think GCC should go down the
EGREP route. glibc is not as friendly to non-GNU based systems
compared to GCC really.
Though I do find that -E/-F have been part of the POSIX standard since
at least 2004 which is interesting.
https://pubs.opengroup.org/onlinepubs/009696899/utilities/grep.html
Though GCC host/build targets can be older and some non-supported ones still.

Thanks,
Andrew Pinski

>
> https://sourceware.org/pipermail/libc-alpha/2022-June/139420.html
>
> > Yes, it is safe nowadays to use 'grep -E' instead of egrep. The only
> > vendor-supported platform I know of where '/usr/bin/grep -E' does not
> > work is Solaris 10 (end-of-life January 2024), and that's easily fixed
> > by prepending /usr/xpg4/bin to PATH.
  

Hi Fangrui,

> FWIW: glibc recently got the grep -E change and the solution is to use
> plain grep -E, without $EGREP things.
> Isn't setting PATH a good workaround if Solaris has the problem?
>
> https://sourceware.org/pipermail/libc-alpha/2022-June/139420.html

while it's possible, the $PATH solution is fragile and I fear the errors
that one gets all over the place when it's missed are highly unintuitive
and hard to diagnose.

>> Yes, it is safe nowadays to use 'grep -E' instead of egrep. The only
>> vendor-supported platform I know of where '/usr/bin/grep -E' does not 
>> work is Solaris 10 (end-of-life January 2024), and that's easily fixed by
>> prepending /usr/xpg4/bin to PATH.

I'm not concerned about Solaris 10 at all: it's no longer supported by
GCC and GDB and while binutils formally still does, there's not much
value in having current binutils with older gcc etc.

	Rainer
  

On Fri, 24 Jun 2022, Andrew Pinski via Gcc-patches wrote:

> Though I do find that -E/-F have been part of the POSIX standard since
> at least 2004 which is interesting.

grep -E and -F are already defined, and egrep and fgrep marked as 
obsolescent, in the 1992/1993 edition of POSIX.2.
  

> On 24 Jun 2022, at 17:09, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> On Fri, 24 Jun 2022, Andrew Pinski via Gcc-patches wrote:
> 
>> Though I do find that -E/-F have been part of the POSIX standard since
>> at least 2004 which is interesting.
> 
> grep -E and -F are already defined, and egrep and fgrep marked as 
> obsolescent, in the 1992/1993 edition of POSIX.2.

FWIW, grep -E/F is supported by the oldest Darwin versions I care about
so, I have no objections to these changes.

Iain