Message ID | 74ea0c62ebe19db186263053e4051f81d46e9da4.camel@xry111.site |
---|---|
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A5142384D1AE for <patchwork@sourceware.org>; Fri, 24 Jun 2022 06:59:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A5142384D1AE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1656053953; bh=vagASYTbK+Pq2JGLxSByoyVCCp/k0pdcUTS9G1KiwfU=; h=Subject:To:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=ILkjWlFE/C1eyRulmA6tLwbRQRHDRNeZzlsN4YZOqaTVZr0MJ9eLrUXTtJhC4FJAE L95TcyVjEElmzQSTB7jW5o4kElVJ1ijahnAgYMGKHY7mtkXwt0m12HJkb0r8FoQA/8 mBRUrT5H65OQLkJ+tsoY1gllhPpkzigW6FTEEiLc= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from xry111.site (xry111.site [IPv6:2001:470:683e::1]) by sourceware.org (Postfix) with ESMTPS id B85F7384D189 for <gcc-patches@gcc.gnu.org>; Fri, 24 Jun 2022 06:57:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B85F7384D189 Received: from localhost.localdomain (xry111.site [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 5BDC166923 for <gcc-patches@gcc.gnu.org>; Fri, 24 Jun 2022 02:57:29 -0400 (EDT) Message-ID: <74ea0c62ebe19db186263053e4051f81d46e9da4.camel@xry111.site> Subject: [PATCH 0/8] Stop using obsoleted egrep/fgrep To: gcc-patches@gcc.gnu.org Date: Fri, 24 Jun 2022 14:57:27 +0800 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.2 MIME-Version: 1.0 X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FROM_SUSPICIOUS_NTLD, FROM_SUSPICIOUS_NTLD_FP, LIKELY_SPAM_FROM, PDS_OTHER_BAD_TLD, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Xi Ruoyao via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Xi Ruoyao <xry111@xry111.site> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
Stop using obsoleted egrep/fgrep
|
|
Message
Xi Ruoyao
June 24, 2022, 6:57 a.m. UTC
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(-)
Comments
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