Re: [PATCH] libcpp: Regenerate aclocal.m4 and configure [PR 114748]

[Eric Gallager]

On Wed, Apr 17, 2024 at 10:03 AM Christophe Lyon
 wrote:
>
> As discussed in the PR, aclocal.m4 and configure were incorrectly
> regenerated at some point.
>
> 2024-04-17  Christophe Lyon  
>
> PR preprocessor/114748
> libcpp/
> * aclocal.m4: Regenerate.
> * configure: Regenerate.
> ---
>  libcpp/aclocal.m4 | 1 +
>  libcpp/configure  | 3 +++
>  2 files changed, 4 insertions(+)
>
> diff --git a/libcpp/aclocal.m4 b/libcpp/aclocal.m4
> index 4fc81709622..4d898ea2c97 100644
> --- a/libcpp/aclocal.m4
> +++ b/libcpp/aclocal.m4
> @@ -26,6 +26,7 @@ m4_include([../config/lib-ld.m4])
>  m4_include([../config/lib-link.m4])
>  m4_include([../config/lib-prefix.m4])
>  m4_include([../config/nls.m4])
> +m4_include([../config/override.m4])
>  m4_include([../config/po.m4])
>  m4_include([../config/progtest.m4])
>  m4_include([../config/warnings.m4])
> diff --git a/libcpp/configure b/libcpp/configure
> index 8a38c0546e3..32d6aaa3069 100755
> --- a/libcpp/configure
> +++ b/libcpp/configure
> @@ -2670,6 +2670,9 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
>
>
>
> +
> +
> +

So, this is kind of a minor style nitpick, but personally, it kind of
bothers me when autotools goes and inserts a bunch of unnecessary
blank newlines in the generated output scripts. Does anyone else think
it'd be worth it to scatter around some of m4's "dnl" comments in the
configure.ac scripts, to get autoconf to eat the unnecessary newlines?
Just an idea,
Eric Gallager

>  ac_aux_dir=
>  for ac_dir in "$srcdir" "$srcdir/.." "$srcdir/../.."; do
>if test -f "$ac_dir/install-sh"; then
> --
> 2.34.1
>

Re: [PATCH] wwwdocs: Add note to changes.html for __has_{feature, extension}

[Eric Gallager]

On Mon, Apr 15, 2024 at 6:14 AM Alex Coplan  wrote:
>
> On 04/04/2024 11:00, Alex Coplan wrote:
> > Hi,
> >
> > This adds a note to the GCC 14 release notes mentioning support for
> > __has_{feature,extension} (PR60512).
> >
> > OK to commit?
>
> Ping.  Is this changes.html patch OK?  I guess it needs a review from C++
> maintainers since it adds to the C++ section.
>

I think it's ok, but then again I can't approve; maybe try the docs
maintainers (i.e. Gerald and/or Sandra) if you don't hear back from
the C++ ones?

> >
> > Thanks,
> > Alex
>
> > diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> > index 9fd224c1..facead8d 100644
> > --- a/htdocs/gcc-14/changes.html
> > +++ b/htdocs/gcc-14/changes.html
> > @@ -242,6 +242,12 @@ a work-in-progress.
> >constinit and optimized dynamic initialization
> >  
> >
> > +  The Clang language extensions __has_feature and
> > +__has_extension have been implemented in GCC.  These
> > +are available from C, C++, and Objective-C(++).
> > +This is primarily intended to aid the portability of code written
> > +against Clang.
> > +  
> >  
> >
> >  Runtime Library (libstdc++)
>

Re: [PATCH] gotools: Workaround non-reproduceability of automake

[Eric Gallager]

On Mon, Apr 15, 2024 at 8:43 AM Jakub Jelinek  wrote:
>
> Hi!
>
> The regen bot recently flagged a difference in gotools/Makefile.in.
> Trying it locally, it seems pretty random
> for i in `seq 20`; do PATH=~/automake-1.15.1/bin:~/autoconf-2.69/bin:$PATH 
> automake; echo -n `git diff Makefile.in | wc -l`" "; done; echo; for i in 
> `seq 20`; do PATH=~/automake-1.15.1/bin:~/autoconf-2.69/bin:$PATH setarch 
> x86_64 -R automake; echo -n `git diff Makefile.in | wc -l`" "; done; echo;
> 14 14 14 0 0 0 14 0 14 0 14 14 14 14 0 14 14 0 0 0
> 14 0 14 0 0 14 14 14 0 14 14 0 0 14 14 14 0 0 0 14
> The 14 line git diff is
> diff --git a/gotools/Makefile.in b/gotools/Makefile.in
> index 36c2ec2abd3..f40883c39be 100644
> --- a/gotools/Makefile.in
> +++ b/gotools/Makefile.in
> @@ -704,8 +704,8 @@ distclean-generic:
>  maintainer-clean-generic:
> @echo "This command is intended for maintainers to use"
> @echo "it deletes files that may require special tools to rebuild."
> -@NATIVE_FALSE@install-exec-local:
>  @NATIVE_FALSE@uninstall-local:
> +@NATIVE_FALSE@install-exec-local:
>  clean: clean-am
>
>  clean-am: clean-binPROGRAMS clean-generic clean-noinstPROGRAMS \
> so whether it is
> @NATIVE_FALSE@install-exec-local:
> @NATIVE_FALSE@uninstall-local:
> or
> @NATIVE_FALSE@uninstall-local:
> @NATIVE_FALSE@install-exec-local:
> depends on some hash table traversal or what.
>
> I'm not familiar with automake/m4 enough to debug that, so I'm
> instead offering a workaround, with this patch the order is deterministic.

Is there a bug open with automake upstream for this?

>
> 2024-04-15  Jakub Jelinek  
>
> * Makefile.am (install-exec-local, uninstall-local): Add goals
> on the else branch of if NATIVE to ensure reproducibility.
> * Makefile.in: Regenerate.
>
> --- gotools/Makefile.am.jj  2023-11-04 09:02:35.802995614 +0100
> +++ gotools/Makefile.am 2024-04-15 14:30:03.647171636 +0200
> @@ -366,5 +366,7 @@ else
>  # only do this if such a compiler is available.  We also need to get
>  # the right values for GOARCH and GOOS in the default build context in
>  # the go/build package.  Figure this out later.
> +install-exec-local:
> +uninstall-local:
>
>  endif
> --- gotools/Makefile.in.jj  2023-11-03 17:08:46.000439645 +0100
> +++ gotools/Makefile.in 2024-04-15 14:31:32.270040117 +0200
> @@ -704,8 +704,6 @@ distclean-generic:
>  maintainer-clean-generic:
> @echo "This command is intended for maintainers to use"
> @echo "it deletes files that may require special tools to rebuild."
> -@NATIVE_FALSE@install-exec-local:
> -@NATIVE_FALSE@uninstall-local:
>  clean: clean-am
>
>  clean-am: clean-binPROGRAMS clean-generic clean-noinstPROGRAMS \
> @@ -1035,6 +1033,8 @@ mostlyclean-local:
>  # only do this if such a compiler is available.  We also need to get
>  # the right values for GOARCH and GOOS in the default build context in
>  # the go/build package.  Figure this out later.
> +@NATIVE_FALSE@install-exec-local:
> +@NATIVE_FALSE@uninstall-local:
>
>  # Tell versions [3.59,3.63) of GNU make to not export all variables.
>  # Otherwise a system limit (for SysV at least) may be exceeded.
>
> Jakub
>

Re: [wwwdocs] gcc-14: Mention that some warnings are now errors

[Eric Gallager]

On Sat, Apr 13, 2024 at 5:51 AM Sebastian Huber
 wrote:
>
> ---
>  htdocs/gcc-14/changes.html | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
> index 8ac08e9a..a183fad8 100644
> --- a/htdocs/gcc-14/changes.html
> +++ b/htdocs/gcc-14/changes.html
> @@ -231,6 +231,17 @@ a work-in-progress.
>previous options -std=c2x, -std=gnu2x
>and -Wc11-c2x-compat, which are deprecated but remain
>supported.
> +  The following warnings are now errors (see also
> +Porting to GCC 14):
> +
> +  -Werror=declaration-missing-parameter-type
> +  -Werror=implicit-function-declaration
> +  -Werror=implicit-int
> +  -Werror=incompatible-pointer-types
> +  -Werror=int-conversion
> +  -Werror=return-mismatch
> +
> +  
>  
>

I'd suggest adding the words "by default" to emphasize that they can
be turned back into warnings, and/or disabled. Perhaps others will
have other wording suggestions.

>  C++
> --
> 2.35.3
>

Re: [PATCH] jit: Ensure ssize_t is defined.

[Eric Gallager]

On Sun, Jan 28, 2024 at 6:45 AM Iain Sandoe  wrote:
>
> Tested on i686, x86_64 Darwin, x86_64 Linux,
> OK for trunk?
>
> --- 8< ---
>
> On some targets it seems that ssize_t is not defined by any of the
> headers transitively included by .  This leads to a bootstrap
> fail when jit is enabled.
>
> The fix proposed here is to include sys/types.h when it is available
> since that is where Posix specifies that ssize_t is defined.
>
> gcc/jit/ChangeLog:
>
> * libgccjit.h: Conditionally include  where it is
> available to ensure declaration of ssize_t.
>
> Signed-off-by: Iain Sandoe 
> ---
>  gcc/jit/libgccjit.h | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
> index 235cab053e0..db4f27a48bf 100644
> --- a/gcc/jit/libgccjit.h
> +++ b/gcc/jit/libgccjit.h
> @@ -21,6 +21,9 @@ along with GCC; see the file COPYING3.  If not see
>  #define LIBGCCJIT_H
>
>  #include 
> +#if __has_include()

Is __has_include() something that we can use unconditionally?

> +# include   /* For ssize_t.  */
> +#endif
>
>  #ifdef __cplusplus
>  extern "C" {
> --
> 2.39.2 (Apple Git-143)
>

Re: [PATCH] Pass GUILE down to subdirectories

[Eric Gallager]

On Thu, Jan 18, 2024 at 3:37 PM Tom Tromey  wrote:
>
> Andrew> This change is causing some problems for me.
>
> Yeah, Tom de Vries as well.
>
> Andrew> One of my build machines has 2 versions of guile installed.  One is
> Andrew> guile 2.0.14 and the other is guile 2.2.21.
>
> Andrew> When GDB configures itself the configure script figures out that it
> Andrew> should use 2.2.21 to compile the guile libraries that GDB uses.
>
> Andrew> However, when we actually build the guile libraries we do use 
> guild2.2,
> Andrew> but due to this 'GUILE = guile' line, guild2.2 uses guile 2.0.14 in
> Andrew> order to perform the compile (I guess, I don't know the details of how
> Andrew> guile compilation works).
>
> Andrew> Unfortunately guile 2.0.14 compiles in a way which is not compatible
> Andrew> with how GDB then tries to load the guile library.
>
> I consider this a bug in guile -- it installs 'guild' with this:
>
> #!/usr/bin/sh
> # -*- scheme -*-
> exec ${GUILE:-/usr/bin/guile2.2} $GUILE_FLAGS -e '(@@ (guild) main)' -s 
> "$0" "$@"
> !#
>
> Allowing a system script to pick $GUILE here seems weird, especially for
> a versioned install of "guild", where as you can see it already knows
> the correct guile to use.
>
> However -- I think it's better to just work around this.
> I plan to back out this change.  Anyone needing to re-run cgen (which
> itself ought to come with smarts here, but since it is un-maintained...)
> can just specify this by hand.  I.e., the status quo ante.

I mean, I've been trying to figure out how to re-run cgen myself, to
regenerate some cgen-erated files in libopcodes to fix some compiler
warnings in them, but it's pretty hard to do so; I'd really appreciate
it if the whole process of regenerating files with cgen could be made
easy and well-documented and understandable...

>
> I'll try to send a patch tomorrow.
>
> Tom

Re: [PATCH] Pass GUILE down to subdirectories

[Eric Gallager]

On Sat, Jan 13, 2024 at 6:36 AM Andrew Burgess  wrote:
>
> Tom Tromey  writes:
>
> > When I enable cgen rebuilding in the binutils-gdb tree, the default is
> > to run cgen using 'guile'.  However, on my host, guile is guile 2.2,
> > which doesn't work for me -- I have to use guile3.0.
> >
> > This patch arranges to pass "GUILE" down to subdirectories, so I can
> > use 'make GUILE=guile3.0'.
> >
> > ChangeLog
> > 2023-12-30  Tom Tromey  
> >
> >   * Makefile.in: Rebuild.
> >   * Makefile.tpl (BASE_EXPORTS): Add GUILE.
> >   (GUILE): New variable.
> >   * Makefile.def (flags_to_pass): Add GUILE.
> > ---
> >  ChangeLog| 7 +++
> >  Makefile.def | 1 +
> >  Makefile.in  | 8 ++--
> >  Makefile.tpl | 7 +--
> >  4 files changed, 19 insertions(+), 4 deletions(-)
> >
> > diff --git a/Makefile.def b/Makefile.def
> > index 662e50fdc18..792919e561c 100644
> > --- a/Makefile.def
> > +++ b/Makefile.def
> > @@ -310,6 +310,7 @@ flags_to_pass = { flag= GNATBIND ; };
> >  flags_to_pass = { flag= GNATMAKE ; };
> >  flags_to_pass = { flag= GDC ; };
> >  flags_to_pass = { flag= GDCFLAGS ; };
> > +flags_to_pass = { flag= GUILE ; };
> >
> >  // Target tools
> >  flags_to_pass = { flag= AR_FOR_TARGET ; };
> > diff --git a/Makefile.in b/Makefile.in
> > index 48320bb549e..9a58d5a4f20 100644
> > --- a/Makefile.in
> > +++ b/Makefile.in
> > @@ -3,7 +3,7 @@
> >  #
> >  # Makefile for directory with subdirs to build.
> >  #   Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
> > -#   1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 
> > 2010, 2011
> > +#   1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 
> > 2010, 2011, 2023
> >  #   Free Software Foundation
> >  #
> >  # This file is free software; you can redistribute it and/or modify
> > @@ -143,7 +143,8 @@ BASE_EXPORTS = \
> >   M4="$(M4)"; export M4; \
> >   SED="$(SED)"; export SED; \
> >   AWK="$(AWK)"; export AWK; \
> > - MAKEINFO="$(MAKEINFO)"; export MAKEINFO;
> > + MAKEINFO="$(MAKEINFO)"; export MAKEINFO; \
> > + GUILE="$(GUILE)"; export GUILE;
> >
> >  # This is the list of variables to export in the environment when
> >  # configuring subdirectories for the build system.
> > @@ -450,6 +451,8 @@ GM2FLAGS = $(CFLAGS)
> >
> >  PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
> >
> > +GUILE = guile
>
> Hi Tom,
>
> This change is causing some problems for me.
>
> One of my build machines has 2 versions of guile installed.  One is
> guile 2.0.14 and the other is guile 2.2.21.
>
> When GDB configures itself the configure script figures out that it
> should use 2.2.21 to compile the guile libraries that GDB uses.
>
> However, when we actually build the guile libraries we do use guild2.2,
> but due to this 'GUILE = guile' line, guild2.2 uses guile 2.0.14 in
> order to perform the compile (I guess, I don't know the details of how
> guile compilation works).
>
> Unfortunately guile 2.0.14 compiles in a way which is not compatible
> with how GDB then tries to load the guile library.
>
> Maybe better to show you what's going on:
>
>   $ pwd
>   /tmp/binutils-gdb/build/gdb/data-directory/guile
>   $ GUILE=guile /usr/bin/guild2.2 compile -Warity-mismatch -Wformat 
> -Wunused-toplevel -L . -o ./gdb.go ./gdb.scm
>   wrote `./gdb.go'
>   $ file gdb.go
>   gdb.go: Guile Object, little endian, 64bit, bytecode v2.0
>   $ GUILE=guile2.2 /usr/bin/guild2.2 compile -Warity-mismatch -Wformat 
> -Wunused-toplevel -L . -o ./gdb.go ./gdb.scm
>   wrote `./gdb.go'
>   $ file gdb.go
>   gdb.go: ELF 64-bit LSB shared object, no machine, version 1 (embedded), 
> dynamically linked, with debug_info, not stripped
>
> The first compile uses GUILE=guile, so I use guile 2.0.14, which results
> in a non-ELF being generated.  When I start GDB with this non-ELF in
> place, I see this:
>
>   $ ./gdb/gdb --data-directory ./gdb/data-directory/
>   Exception caught while booting Guile.
>   Error in function "load-thunk-from-memory":
>   not an ELF file
>   ./gdb/gdb: warning: Could not complete Guile gdb module initialization from:
>   /tmp/binutils-gdb/build/gdb/data-directory/guile/gdb/boot.scm.
>   Limited Guile support is available.
>   Suggest passing --data-directory=/path/to/gdb/data-directory.
>   GDB Version: 15.1
>
>   (gdb)
>
> The second compile, with GUILE=guile2.2 results in an ELF being
> generated, and with this in place GDB starts just fine.
>
> Now, clearly the obvious answer is: don't have such an old, out of date
> version of guile installed.  But I think there's a bigger issue here.
> As guild version X will by default pick up the corresponding version of
> guile, shouldn't that be the default behaviour?
>
> My proposal would be that we change the line 'GUILE = guile' to instead
> be just 'GUILE ='.
>
> With this in place I can still override the choice of guile executable
> with:
>
>   make GUILE=guile
>
> but, if I don't do this then instead of forcing 'guile' as the default,
> we allow the guild 

Re: [PATCH] remove qmtest-related Makefile targets

[Eric Gallager]

On Wed, Dec 6, 2023 at 12:56 PM Jeff Law  wrote:
> On 12/5/23 09:41, Eric Gallager wrote:
> > On GitHub, Joseph Myers (@jsm28 there) says in MentorEmbedded/qmtest#1
> > that the qmtest-related targets should have been removed long ago. This
> > patch does so.
> >
> > Ref:
> > https://github.com/MentorEmbedded/qmtest/issues/1
> >
> > gcc/ChangeLog:
> >
> >   * Makefile.in: Remove qmtest-related targets.
> In hindsight I probably should have been more supportive of the QMTest
> effort.  But it's dead now.
>
> OK for the trunk.
>
> jeff

Thanks, committed as r14-6230-gec266cbb859160:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ec266cbb859160aa207b6b292cfd974280ca8ff9

Re: [C PATCH, v2] Add Walloc-size to warn about insufficient size in allocations [PR71219]

[Eric Gallager]

On Wed, Dec 6, 2023 at 10:13 AM Martin Uecker  wrote:
>
> Am Mittwoch, dem 06.12.2023 um 16:01 +0100 schrieb Jakub Jelinek:
> > On Wed, Dec 06, 2023 at 03:56:10PM +0100, Martin Uecker wrote:
> > > > That would be my preference because then the allocation size is
> > > > correct and it is purely a style warning.
> > > > It doesn't follow how the warning is described:
> > > > "Warn about calls to allocation functions decorated with attribute
> > > > @code{alloc_size} that specify insufficient size for the target type of
> > > > the pointer the result is assigned to"
> > > > when the size is certainly sufficient.
> > >
> > > The C standard defines the semantics of to allocate space
> > > of 'nmemb' objects of size 'size', so I would say
> > > the warning and its description are correct because
> > > if you call calloc with '1' as size argument but
> > > the object size is larger then you specify an
> > > insufficient size for the object given the semantical
> > > description of calloc in the standard.
> >
> > 1 is sizeof (char), so you ask for an array of sizeof (struct ...)
> > chars and store the struct into it.
>
> If you use
>
> char *p = calloc(sizeof(struct foo), 1);
>
> it does not warn.
>
> >
> > > > We have the -Wmemset-transposed-args warning, couldn't we
> > > > have a similar one for calloc, and perhaps do it solely in
> > > > the case where one uses sizeof of the type used in the cast
> > > > pointer?
> > > > So warn for
> > > > (struct S *) calloc (sizeof (struct S), 1)
> > > > or
> > > > (struct S *) calloc (sizeof (struct S), n)
> > > > but not for
> > > > (struct S *) calloc (4, 15)
> > > > or
> > > > (struct S *) calloc (sizeof (struct T), 1)
> > > > or similar?  Of course check for compatible types of TYPE_MAIN_VARIANTs.
> > >
> > > Yes, although in contrast to -Wmeset-transposed-args
> > > this would be considered a "style" option which then
> > > nobody would activate.  And if we put it into -Wextra
> > > then we have the same situation as today.
> >
> > Well, the significant difference would be that users would
> > know that they got the size for the allocation right, just
> > that a coding style says it is better to put the type's size
> > as the second argument rather than first, and they could disable
> > that warning separately from -Walloc-size and still get warnings
> > on (struct S *) calloc (1, 1) or (struct S *) malloc (3) if
> > sizeof (struct S) is 24...
>
> Ok.
>
> Note that another limitation of the current version is that it
> does not warn for
>
> ... = (struct S*) calloc (...)
>
> with the cast (which is non-idiomatic in C).

Note that -Wc++-compat encourages the cast, for people who are trying
to make their code compilable as both C and C++.

> This is also
> something I would like to address in the future and would be
> more important for the C++ version.  But for this case it
> should probably use the type of the cast and the warning
> needs to be added somewhere else in the FE.
>
>
> Martin
>

Re: [PATCH] gettext: disable install, docs targets, libasprintf, threads

[Eric Gallager]

On Mon, Dec 4, 2023 at 1:44 PM Tom Tromey  wrote:
>
> > "Arsen" == Arsen Arsenović  writes:
>
> Arsen> Thanks.  I'll wait for the Binutils and GDB maintainers to weigh in
> Arsen> before pushing (plus, I can't push there).
>
> Seems fine to me.  Thank you.
>
> Tom

LGTM; please post once it has been committed.
Thanks,
Eric

[PATCH] remove qmtest-related Makefile targets

[Eric Gallager]

On GitHub, Joseph Myers (@jsm28 there) says in MentorEmbedded/qmtest#1
that the qmtest-related targets should have been removed long ago. This
patch does so.

Ref:
https://github.com/MentorEmbedded/qmtest/issues/1

gcc/ChangeLog:

* Makefile.in: Remove qmtest-related targets.
---
 gcc/Makefile.in | 53 -
 1 file changed, 53 deletions(-)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index e154f7c0055..f80aa09ef74 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3733,7 +3733,6 @@ distclean: clean lang.distclean
-rm -f testsuite/*.log testsuite/*.sum
-cd testsuite && rm -f x *.x *.x? *.exe *.rpo *.o *.s *.S *.cc
-cd testsuite && rm -f *.out *.gcov *$(coverageexts)
-   -rm -rf ${QMTEST_DIR} stamp-qmtest
-rm -f .gdbinit configargs.h
-rm -f gcov.pod
 # Delete po/*.gmo only if we are not building in the source directory.
@@ -4415,58 +4414,6 @@ check-parallel-% : site.exp
  fi ; \
fi )
 
-# QMTest targets
-
-# The path to qmtest.
-QMTEST_PATH=qmtest
-
-# The flags to pass to qmtest.
-QMTESTFLAGS=
-
-# The flags to pass to "qmtest run".
-QMTESTRUNFLAGS=-f none --result-stream dejagnu_stream.DejaGNUStream
-
-# The command to use to invoke qmtest.
-QMTEST=${QMTEST_PATH} ${QMTESTFLAGS}
-
-# The tests (or suites) to run.
-QMTEST_GPP_TESTS=g++
-
-# The subdirectory of the OBJDIR that will be used to store the QMTest
-# test database configuration and that will be used for temporary
-# scratch space during QMTest's execution.
-QMTEST_DIR=qmtestsuite
-
-# Create the QMTest database configuration.
-${QMTEST_DIR} stamp-qmtest:
-   ${QMTEST} -D ${QMTEST_DIR} create-tdb \
-   -c gcc_database.GCCDatabase \
-   -a srcdir=`cd ${srcdir}/testsuite && ${PWD_COMMAND}` && \
-   $(STAMP) stamp-qmtest
-
-# Create the QMTest context file.
-${QMTEST_DIR}/context: stamp-qmtest
-   rm -f $@
-   echo "CompilerTable.languages=c cplusplus" >> $@
-   echo "CompilerTable.c_kind=GCC" >> $@
-   echo "CompilerTable.c_path=${objdir}/xgcc" >> $@
-   echo "CompilerTable.c_options=-B${objdir}/" >> $@
-   echo "CompilerTable.cplusplus_kind=GCC" >> $@
-   echo "CompilerTable.cplusplus_path=${objdir}/xg++" >> $@
-   echo "CompilerTable.cplusplus_options=-B${objdir}/" >> $@
-   echo "DejaGNUTest.target=${target_noncanonical}" >> $@
-
-# Run the G++ testsuite using QMTest.
-qmtest-g++: ${QMTEST_DIR}/context
-   cd ${QMTEST_DIR} && ${QMTEST} run ${QMTESTRUNFLAGS} -C context \
-  -o g++.qmr ${QMTEST_GPP_TESTS}
-
-# Use the QMTest GUI.
-qmtest-gui: ${QMTEST_DIR}/context
-   cd ${QMTEST_DIR} && ${QMTEST} gui -C context
-
-.PHONY: qmtest-g++
-
 # Run Paranoia on real.cc.
 
 paranoia.o: $(srcdir)/../contrib/paranoia.cc $(CONFIG_H) $(SYSTEM_H) $(TREE_H)
-- 
2.32.0 (Apple Git-132)

Re: [PATCH v2] doc: Update the status of build directory not fully separated

[Eric Gallager]

Please cross-reference against issue 37210 if/when merging, if it
hasn't already been:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37210

On Fri, Dec 1, 2023 at 2:15 AM Richard Biener
 wrote:
>
> On Thu, Nov 30, 2023 at 2:42 PM Xi Ruoyao  wrote:
> >
> > Recently there are some people building GCC with srcdir == objdir and
> > the attempts just failed [1].  So stop to say "it should work".  OTOH
> > objdir as a subdirectory of srcdir works: we've built GCC in LFS [2]
> > and BLFS [3] this way for decades and this is confirmed during the
> > review of a previous version of this patch [4].
> >
> > [1]: https://gcc.gnu.org/pipermail/gcc-help/2023-November/143068.html
> > [2]: https://www.linuxfromscratch.org/lfs/view/12.0/chapter08/gcc.html
> > [3]: https://www.linuxfromscratch.org/blfs/view/12.0/general/gcc.html
> > [4]: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638760.html>
>
> > gcc/ChangeLog:
> >
> > * doc/install.texi: Deem srcdir == objdir broken, but objdir
> > as a subdirectory of srcdir fine.
> > ---
> >
> > Superseds
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638728.html.
> >
> > Ok for trunk?
>
> OK.
>
> Thanks,
> Richard.
>
> >  gcc/doc/install.texi | 5 ++---
> >  1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> > index c1ccb8ba02d..c1128d9274c 100644
> > --- a/gcc/doc/install.texi
> > +++ b/gcc/doc/install.texi
> > @@ -697,9 +697,8 @@ phases.
> >  First, we @strong{highly} recommend that GCC be built into a
> >  separate directory from the sources which does @strong{not} reside
> >  within the source tree.  This is how we generally build GCC; building
> > -where @var{srcdir} == @var{objdir} should still work, but doesn't
> > -get extensive testing; building where @var{objdir} is a subdirectory
> > -of @var{srcdir} is unsupported.
> > +where @var{objdir} is a subdirectory of @var{srcdir} should work as well;
> > +building where @var{objdir} == @var{srcdir} is unsupported.
> >
> >  If you have previously built GCC in the same directory for a
> >  different target machine, do @samp{make distclean} to delete all files
> > --
> > 2.43.0
> >

Re: [PATCH v3 0/2] Replace intl/ with out-of-tree GNU gettext

[Eric Gallager]

On Tue, Nov 21, 2023 at 8:51 AM Arsen Arsenović  wrote:
>
>
> Arsen Arsenović  writes:
>
> > Bruno Haible  writes:
> >
> >> Arsen Arsenović wrote:
> >>>   Comparing stages 2 and 3
> >>>   Bootstrap comparison failure!
> >>>   gettext/libasprintf/autosprintf.o differs
> >>>   make[2]: *** [Makefile:23435: compare] Error 1
> >>
> >> You should be able to work around this by passing the additional option
> >> --disable-libasprintf to gettext-runtime/configure. Nothing in GCC needs
> >> libasprintf; therefore there is no need to build it.
> >
> > Ah, sure, that works for me too (note that the fix is to pass
> > -frandom-seed=, according to Jakub, should this show up again).
>
> Indeed, that got a bootstrap to pass.  I've also taken the opportunity
> to check the problems Eric Gallager reported.  The install tree seems
> clean now, and the info et al targets appear to work again.  David,
> Eric, could you check whether the attached patch works for you in the
> scenarios you ran into problems with?  Make sure to fetch gettext-0.22.4
> into your trees.
>

OK, I can confirm that with this patch, my GitHub Actions CI workflow
that had previously been failing is now passing again; you can see the
results here:
https://github.com/cooljeanius/gcc/actions/runs/6948834515/job/18905670645
...and here's a link to a zip of the logfiles generated from the build:
https://github.com/cooljeanius/gcc/suites/18389727422/artifacts/1065350046

>
> If these work, I'll update download_prerequisites and see about posting
> the patch for review.
>
> Thanks, have a lovely day.
>
> >> And while at it, I would also pass --disable-java and --disable-csharp.
> >
> > Yes, I noticed those and disabled them already.
> >
> >> Bruno
>
>
> --
> Arsen Arsenović

Re: [PATCH v3 11/11] c: Add new -Wdeclaration-missing-parameter-type permerror

[Eric Gallager]

On Mon, Nov 20, 2023 at 4:58 AM Florian Weimer  wrote:
>
> This used to be a warning, enabled by default, without its own option.

Right, I meant to ask: why create a new option of
-Wdeclaration-missing-parameter-type instead of reusing the existing
-Wmissing-parameter-type for this?

>
> A subsequent change could improve diagnostics and provide spelling
> hints for declarations like “void function (int32t);”.
>
> gcc/c-family/
>
> * c.opt (Wdeclaration-missing-parameter-type): New.
>
> gcc/c/ChangeLog:
>
> PR other/44209
> * c-decl.cc (grokparms): Issue permerror for
> OPT_Wdeclaration_missing_parameter_type instead of a pedwarn.
>
> gcc/ChangeLog:
>
> * doc/invoke.texi (Warning Options): Document
> -Wdeclaration-missing-parameter-type.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/permerror-default.c (missing_parameter_type):
> Expect error.
> * gcc.dg/permerror-fpermissive.c (missing_parameter_type):
> Expect -Wdeclaration-missing-parameter-type warning.
> * gcc.dg/permerror-gnu89-nopermissive.c (missing_parameter_type):
> Expect -Wdeclaration-missing-parameter-type error.
> * gcc.dg/permerror-gnu89-pedantic.c (missing_parameter_type):
> Likewise.
> * gcc.dg/permerror-gnu89.c (missing_parameter_type):
> Expect -Wdeclaration-missing-parameter-type warning.
> * gcc.dg/permerror-noerror.c: Add
> -Wno-error=declaration-missing-parameter-type to build flags.
> (missing_parameter_type): Expect
> -Wdeclaration-missing-parameter-type warning.
> * gcc.dg/permerror-nowarning.c: Build with
> -Wno-declaration-missing-parameter-type.  Remove previously
> expected warning.
> * gcc.dg/permerror-fpermissive-nowarning.c: Likewise.
> * gcc.dg/permerror-pedantic.c (missing_parameter_type):
> Expect -Wdeclaration-missing-parameter-type error.
> * gcc.dg/permerror-system.c (missing_parameter_type):
> Likewise.
> ---
>  gcc/c-family/c.opt  |  4 
>  gcc/c/c-decl.cc |  6 --
>  gcc/doc/invoke.texi | 17 -
>  gcc/testsuite/gcc.dg/permerror-default.c|  2 +-
>  .../gcc.dg/permerror-fpermissive-nowarning.c|  7 +--
>  gcc/testsuite/gcc.dg/permerror-fpermissive.c|  2 +-
>  .../gcc.dg/permerror-gnu89-nopermissive.c   |  2 +-
>  gcc/testsuite/gcc.dg/permerror-gnu89-pedantic.c |  2 +-
>  gcc/testsuite/gcc.dg/permerror-gnu89.c  |  2 +-
>  gcc/testsuite/gcc.dg/permerror-noerror.c|  4 ++--
>  gcc/testsuite/gcc.dg/permerror-nowarning.c  |  7 +--
>  gcc/testsuite/gcc.dg/permerror-pedantic.c   |  2 +-
>  gcc/testsuite/gcc.dg/permerror-system.c |  2 ++
>  13 files changed, 36 insertions(+), 23 deletions(-)
>
> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
> index b10c6057cd1..723e8c3e27b 100644
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -591,6 +591,10 @@ Wdeclaration-after-statement
>  C ObjC Var(warn_declaration_after_statement) Init(-1) Warning
>  Warn when a declaration is found after a statement.
>
> +Wdeclaration-missing-parameter-type
> +C ObjC Var(warn_declaration_missing_parameter) Warning Init(1)
> +Warn for missing parameter types in function declarations.
> +
>  Wdelete-incomplete
>  C++ ObjC++ Var(warn_delete_incomplete) Init(1) Warning
>  Warn when deleting a pointer to incomplete type.
> diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
> index d16958113a8..3d9bee54259 100644
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
> @@ -8337,8 +8337,10 @@ grokparms (struct c_arg_info *arg_info, bool 
> funcdef_flag)
>  {
>if (!funcdef_flag)
> {
> - pedwarn (input_location, 0, "parameter names (without types) in "
> -  "function declaration");
> + permerror_opt (input_location,
> +OPT_Wdeclaration_missing_parameter_type,
> +"parameter names (without types) in "
> +"function declaration");
>   arg_info->parms = NULL_TREE;
> }
>else
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index be33da71c44..7f5da45dcea 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -504,7 +504,8 @@ Objective-C and Objective-C++ Dialects}.
>
>  @item C and Objective-C-only Warning Options
>  @gccoptlist{-Wbad-function-cast  -Wmissing-declarations
> --Wmissing-parameter-type -Wmissing-prototypes -Wmissing-variable-declarations
> +-Wmissing-parameter-type -Wdeclaration-missing-parameter-type
> +-Wmissing-prototypes -Wmissing-variable-declarations
>  -Wnested-externs -Wold-style-declaration  -Wold-style-definition
>  -Wstrict-prototypes  -Wtraditional  -Wtraditional-conversion
>  -Wdeclaration-after-statement  -Wpointer-sign}
> @@ -9734,6 +9735,20 @@ void foo(bar) @{ @}
>
>  This warning 

Re: [PATCH] C99 testsuite readiness: -fpermissive tests

[Eric Gallager]

On Fri, Nov 10, 2023 at 5:06 PM Florian Weimer  wrote:
>
> These tests use obsolete language constructs, but they are not
> clearly targeting C89, either.  So use -fpermissive to keep
> future errors as warnings.
>
> The reasons why obsolete constructs are used used vary from
> test to test.  Some tests deliberately exercise later stages
> of the compiler that only occur with those constructs.  Some
> tests have precise expectations about warnings that will become
> errors with a future change, but do not specifically test a
> particular warning/error (if that is the case, the later changes
> tend to duplicate them into warning/error variants).  In a few
> cases, use of obsolete constructs is clearly due to test case
> reduction, but it was not possible to un-reduce the test due
> to its size.
>
> gcc/testsuite/
>
> * c-c++-common/Wduplicated-branches-11.c: Compile with
> -fpermissive.
> * c-c++-common/Wduplicated-branches-12.c: Likewise.
> * c-c++-common/builtins.c: Likewise.
> * c-c++-common/pointer-to-fn1.c: Likewise.
> * gcc.c-torture/compile/20010320-1.c: Likewise.
> * gcc.c-torture/compile/20050105-1.c: Likewise.
> * gcc.c-torture/compile/20080704-1.c: Likewise.
> * gcc.c-torture/compile/20080910-1.c: Likewise.
> * gcc.c-torture/compile/20090917-1.c: Likewise.
> * gcc.c-torture/compile/20100915-1.c: Likewise.
> * gcc.c-torture/compile/20101216-1.c: Likewise.
> * gcc.c-torture/compile/20121027-1.c: Likewise.
> * gcc.c-torture/compile/20180605-1.c: Likewise.
> * gcc.c-torture/compile/950816-2.c: Likewise.
> * gcc.c-torture/compile/dse.c: Likewise.
> * gcc.c-torture/compile/pr100576.c: Likewise.
> * gcc.c-torture/compile/pr17408.c: Likewise.
> * gcc.c-torture/compile/pr19121.c: Likewise.
> * gcc.c-torture/compile/pr26213.c: Likewise.
> * gcc.c-torture/compile/pr27341-2.c: Likewise.
> * gcc.c-torture/compile/pr28776-2.c: Likewise.
> * gcc.c-torture/compile/pr33133.c: Likewise.
> * gcc.c-torture/compile/pr34091.c: Likewise.
> * gcc.c-torture/compile/pr36154.c: Likewise.
> * gcc.c-torture/compile/pr37381.c: Likewise.
> * gcc.c-torture/compile/pr38360.c: Likewise.
> * gcc.c-torture/compile/pr40291.c: Likewise.
> * gcc.c-torture/compile/pr41182-1.c: Likewise.
> * gcc.c-torture/compile/pr43635.c: Likewise.
> * gcc.c-torture/compile/pr44043.c: Likewise.
> * gcc.c-torture/compile/pr44063.c: Likewise.
> * gcc.c-torture/compile/pr44246.c: Likewise.
> * gcc.c-torture/compile/pr45535.c: Likewise.
> * gcc.c-torture/compile/pr46934.c: Likewise.
> * gcc.c-torture/compile/pr47428.c: Likewise.
> * gcc.c-torture/compile/pr49145.c: Likewise.
> * gcc.c-torture/compile/pr49206.c: Likewise.
> * gcc.c-torture/compile/pr51694.c: Likewise.
> * gcc.c-torture/compile/pr53886.c: Likewise.
> * gcc.c-torture/compile/pr65241.c: Likewise.
> * gcc.c-torture/compile/pr72802.c: Likewise.
> * gcc.c-torture/compile/pr81360.c: Likewise.
> * gcc.c-torture/compile/pr82052.c: Likewise.
> * gcc.c-torture/compile/pr90275-2.c: Likewise.
> * gcc.c-torture/compile/pr90275.c: Likewise.
> * gcc.c-torture/compile/pr96796.c: Likewise.
> * gcc.c-torture/compile/regs-arg-size.c: Likewise.
> * gcc.c-torture/compile/udivmod4.c: Likewise.
> * gcc.c-torture/compile/widechar-1.c: Likewise.
> * gcc.c-torture/execute/2412-3.c: Likewise.
> * gcc.c-torture/execute/20010605-2.c: Likewise.
> * gcc.c-torture/execute/20020314-1.c: Likewise.
> * gcc.c-torture/execute/20020819-1.c: Likewise.
> * gcc.c-torture/execute/20031211-2.c: Likewise.
> * gcc.c-torture/execute/20040223-1.c: Likewise.
> * gcc.c-torture/execute/20041019-1.c: Likewise.
> * gcc.c-torture/execute/20120427-1.c: Likewise.
> * gcc.c-torture/execute/20120427-2.c: Likewise.
> * gcc.c-torture/execute/920908-2.c: Likewise.
> * gcc.c-torture/execute/921110-1.c: Likewise.
> * gcc.c-torture/execute/930111-1.c: Likewise.
> * gcc.c-torture/execute/930208-1.c: Likewise.
> * gcc.c-torture/execute/930702-1.c: Likewise.
> * gcc.c-torture/execute/930818-1.c: Likewise.
> * gcc.c-torture/execute/931017-1.c: Likewise.
> * gcc.c-torture/execute/931018-1.c: Likewise.
> * gcc.c-torture/execute/931208-1.c: Likewise.
> * gcc.c-torture/execute/941101-1.c: Likewise.
> * gcc.c-torture/execute/941110-1.c: Likewise.
> * gcc.c-torture/execute/950322-1.c: Likewise.
> * gcc.c-torture/execute/950426-1.c: Likewise.
> * gcc.c-torture/execute/950512-1.c: Likewise.
> * gcc.c-torture/execute/950621-1.c: Likewise.
> * 

Re: [PING] Re: [PATCH] Add files to discourage submissions of PRs to the GitHub mirror.

[Eric Gallager]

On Wed, Nov 1, 2023 at 7:25 PM Eric Gallager  wrote:
>
> On Wed, Nov 1, 2023 at 11:31 AM Jeff Law  wrote:
> >
> >
> >
> > On 11/1/23 08:11, Eric Gallager wrote:
> > > Hi, I'd like to ping the following patch:
> > >
> > > https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633191.html
> > OK for the trunk.
> >
>
> Thanks, committed as r14-5064-g2b9778c8d9d331:
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=2b9778c8d9d33174de63716b74b2f114d700e104

...and then I cleaned up the formatting a bit in
r14-5065-g4968e4844a3ce3, which I pushed under the "obvious" rule:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=4968e4844a3ce30143ae2e267895c418f5c636a1

>
> > jeff

Re: [PING] Re: [PATCH] Add files to discourage submissions of PRs to the GitHub mirror.

[Eric Gallager]

On Wed, Nov 1, 2023 at 11:31 AM Jeff Law  wrote:
>
>
>
> On 11/1/23 08:11, Eric Gallager wrote:
> > Hi, I'd like to ping the following patch:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633191.html
> OK for the trunk.
>

Thanks, committed as r14-5064-g2b9778c8d9d331:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=2b9778c8d9d33174de63716b74b2f114d700e104

> jeff

[PING] Re: [PATCH] Add files to discourage submissions of PRs to the GitHub mirror.

[Eric Gallager]

Hi, I'd like to ping the following patch:

https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633191.html

On Mon, Oct 16, 2023 at 8:50 PM Eric Gallager  wrote:
>
> On Mon, Oct 16, 2023 at 7:58 PM Andrew Pinski  wrote:
> >
> > On Mon, Oct 16, 2023, 16:39 Eric Gallager  wrote:
> >>
> >> Currently there is an unofficial mirror of GCC on GitHub that people
> >> sometimes submit pull requests to:
> >> https://github.com/gcc-mirror/gcc
> >> However, this is not the proper way to contribute to GCC, so that means
> >> that someone (usually Jonathan Wakely) has to go through the PRs and
> >> manually tell people that they're sending their PRs to the wrong place.
> >> One thing that would help mitigate this problem would be files in a
> >> special .github directory that GitHub would automatically open when
> >> contributors attempt to open a PR, that would then tell them the proper
> >> way to contribute instead. This patch attempts to add two such files.
> >> They are written in Markdown, which I'm realizing might require some
> >> special handling in this repository, since the ".md" extension is also
> >> used for GCC's "Machine Description" files here, but I'm not quite sure
> >> how to go about handling that. Also note that I adapted these files from
> >> equivalent files in the git repository for Git itself:
> >> https://github.com/git/git/blob/master/.github/CONTRIBUTING.md
> >> https://github.com/git/git/blob/master/.github/PULL_REQUEST_TEMPLATE.md
> >> What do people think?
> >
> >
> >
> > I think this is a great idea. Is a similar one for opening issues too?
> >
>
> One for issues isn't necessary, because the GitHub mirror has never
> had issues enabled in the first place, so people already can't open
> issues there.
>
> > Thanks,
> > Andrew
> >
> >
> >> ChangeLog:
> >>
> >> * .github/CONTRIBUTING.md: New file.
> >> * .github/PULL_REQUEST_TEMPLATE.md: New file.
> >> ---
> >>  .github/CONTRIBUTING.md  | 18 ++
> >>  .github/PULL_REQUEST_TEMPLATE.md |  5 +
> >>  2 files changed, 23 insertions(+)
> >>  create mode 100644 .github/CONTRIBUTING.md
> >>  create mode 100644 .github/PULL_REQUEST_TEMPLATE.md
> >>
> >> diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
> >> new file mode 100644
> >> index ..4f7b3abca5f4
> >> --- /dev/null
> >> +++ b/.github/CONTRIBUTING.md
> >> @@ -0,0 +1,18 @@
> >> +## Contributing to GCC
> >> +
> >> +Thanks for taking the time to contribute to GCC! Please be advised that 
> >> if you are
> >> +viewing this on `github.com`, that the mirror there is unofficial and 
> >> unmonitored.
> >> +The GCC community does not use `github.com` for their contributions. 
> >> Instead, we use
> >> +a mailing list (`gcc-patches@gcc.gnu.org`) for code submissions, code
> >> +reviews, and bug reports.
> >> +
> >> +Perhaps one day it will be possible to use 
> >> [GitGitGadget](https://gitgitgadget.github.io/) to
> >> +conveniently send Pull Requests commits to GCC's mailing list, the way 
> >> that the Git project currently allows it to be used to send PRs to their 
> >> mailing list, but until that day arrives, please send your patches to the 
> >> mailing list manually.
> >> +
> >> +Please read ["Contributing to GCC"](https://gcc.gnu.org/contribute.html) 
> >> on the main GCC website
> >> +to learn how the GCC project is managed, and how you can work with it.
> >> +In addition, we highly recommend you to read [our guidelines for 
> >> read-write Git access](https://gcc.gnu.org/gitwrite.html).
> >> +
> >> +Or, you can follow the ["Contributing to GCC in 10 easy 
> >> steps"](https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps)
> >>  section of the ["Getting Started" 
> >> page](https://gcc.gnu.org/wiki/GettingStarted) on [the 
> >> wiki](https://gcc.gnu.org/wiki) for another example of the contribution 
> >> process.
> >> +
> >> +Your friendly GCC community!
> >> diff --git a/.github/PULL_REQUEST_TEMPLATE.md 
> >> b/.github/PULL_REQUEST_TEMPLATE.md
> >> new file mode 100644
> >> index ..6417392c8cf3
> >> --- /dev/null
> >> +++ b/.github/PULL_REQUEST_TEMPLATE.md
> >> @@ -0,0 +1,5 @@
> >> +Thanks for taking the time to contribute to GCC! Please be advised that 
> >> if you are
> >> +viewing this on `github.com`, that the mirror there is unofficial and 
> >> unmonitored.
> >> +The GCC community does not use `github.com` for their contributions. 
> >> Instead, we use
> >> +a mailing list (`gcc-patches@gcc.gnu.org`) for code submissions, code 
> >> reviews, and
> >> +bug reports. Please send patches there instead.

Re: [PATCH] gcc.c-torture/execute/builtins/fputs.c: Define _GNU_SOURCE

[Eric Gallager]

On Sun, Oct 22, 2023 at 4:03 PM  wrote:
>
> On 22 October 2023 21:45:12 CEST, Jeff Law  wrote:
> >
> >
> >On 10/22/23 10:09, Andrew Pinski wrote:
> >> On Sun, Oct 22, 2023 at 12:47 AM Florian Weimer  wrote:
> >>>
> >>> Current glibc headers only declare fputs_unlocked for _GNU_SOURCE.
> >>> Defining the macro avoids an implicit function declaration.
> >>
> >> This does not help targets that don't use glibc though.
> >> Note for builtins testsuite there is a lib-fputs.c file which will
> >> define a fputs_unlock which is how it will link even if the libc does
> >> not define a fputs_unlock.
> >But isn't fputs_unlocked glibc specific to begin with?  ie, the test really 
> >doesn't make sense AFAICT on non-glibc targets.
>
> I think uClibc had it too, at least at one point in the past.
>

gnulib has these portability notes about fputs_unlocked:
https://www.gnu.org/software/gnulib/manual/html_node/fputs_005funlocked.html
Unfortunately, it only lists the platforms that *don't* have it, not
the ones that *do* have it, so I'm afraid its notes aren't actually
that helpful after all... oh well, never mind...

Re: [MAINTAINERS/KERNEL SUMMIT] Trust and maintenance of file systems

[Eric Gallager]

On Tue, Sep 12, 2023 at 5:53 AM Richard Biener via Gcc-patches
 wrote:
>
> On Thu, Sep 7, 2023 at 2:32 PM Segher Boessenkool
>  wrote:
> >
> > On Thu, Sep 07, 2023 at 02:23:00PM +0300, Dan Carpenter wrote:
> > > On Thu, Sep 07, 2023 at 06:04:09AM -0500, Segher Boessenkool wrote:
> > > > On Thu, Sep 07, 2023 at 12:48:25PM +0300, Dan Carpenter via Gcc-patches 
> > > > wrote:
> > > > > I started to hunt
> > > > > down all the Makefile which add a -Werror but there are a lot and
> > > > > eventually I got bored and gave up.
> > > >
> > > > I have a patch stack for that, since 2014 or so.  I build Linux with
> > > > unreleased GCC versions all the time, so pretty much any new warning is
> > > > fatal if you unwisely use -Werror.
> > > >
> > > > > Someone should patch GCC so there it checks an environment variable to
> > > > > ignore -Werror.  Somethine like this?
> > > >
> > > > No.  You should patch your program, instead.
> > >
> > > There are 2930 Makefiles in the kernel source.
> >
> > Yes.  And you need patches to about thirty.  Or a bit more, if you want
> > to do it more cleanly.  This isn't a guess.
> >
> > > > One easy way is to add a
> > > > -Wno-error at the end of your command lines.  Or even just -w if you
> > > > want or need a bigger hammer.
> > >
> > > I tried that.  Some of the Makefiles check an environemnt variable as
> > > well if you want to turn off -Werror.  It's not a complete solution at
> > > all.  I have no idea what a complete solution looks like because I gave
> > > up.
> >
> > A solution can not involve changing the compiler.  That is just saying
> > the kernel doesn't know how to fix its own problems, so let's give the
> > compiler some more unnecessary problems.
>
> You can change the compiler by replacing it with a script that appends
> -Wno-error
> for example.

I personally would find the original proposal of an IGNORE_WERROR
environment variable much simpler than any of the alternative proposed
solutions, especially for complicated build systems where I can't tell
where the "-Werror" is getting inserted from. Often times I'm not
actually the developer of the package I'm trying to compile, so saying
"fix your code" in such a case doesn't make sense, since it's not
actually my code to fix in the first place. It would be much easier
for end-users in such a situation to just set an environment variable,
rather than asking them to try to become developers themselves, which
is what some of these alternative proposals (such as "write your own
script!") seem to be asking.

>
> > > > Or nicer, put it all in Kconfig, like powerpc already has for example.
> > > > There is a CONFIG_WERROR as well, so maybe use that in all places?
> > >
> > > That's a good idea but I'm trying to compile old kernels and not the
> > > current kernel.
> >
> > You can patch older kernels, too, you know :-)
> >
> > If you need to not make any changes to your source code for some crazy
> > reason (political perhaps?), just use a shell script or shell function
> > instead of invoking the compiler driver directly?
> >
> >
> > Segher
> >
> > Segher

Re: [PATCH] c: Add -Wreturn-mismatch warning, split from -Wreturn-type

[Eric Gallager]

On Thu, Oct 19, 2023 at 5:08 PM Florian Weimer  wrote:
>
> The existing -Wreturn-type option covers both constraint violations
> (which are mandatory to diagnose) and warnings that have known
> false positives.  The new -Wreturn-mismatch warning is only about
> the constraint violations (missing or extra return expressions),
> and should eventually be turned into a permerror.
>
> The -std=gnu89 test cases show that by default, we do not warn for
> return; in a function not returning void.  This matches previous
> practice for -Wreturn-type.
>
> gcc/c-family/
>
> * c.opt (Wreturn-mismatch): New.
>
> gcc/c/
>
> * c-typeck.cc (c_finish_return): Use pedwarn with
> OPT_Wreturn_mismatch for missing/extra return expressions.
>
> gcc/
>
> * doc/invoke.texi (Warning Options): Document
> -Wreturn-mismatch.  Update -Wreturn-type documentation.
>
> gcc/testsuite/
>
> * gcc.dg/Wreturn-mismatch-1.c: New.
> * gcc.dg/Wreturn-mismatch-2.c: New.
> * gcc.dg/Wreturn-mismatch-3.c: New.
> * gcc.dg/Wreturn-mismatch-4.c: New.
> * gcc.dg/Wreturn-mismatch-5.c: New.
> * gcc.dg/noncompile/pr55976-1.c: Change -Werror=return-type
> to -Werror=return-mismatch.
> * gcc.dg/noncompile/pr55976-2.c: Likewise.
>
> ---
>  gcc/c-family/c.opt  |  4 +++
>  gcc/c/c-typeck.cc   | 15 +++
>  gcc/doc/invoke.texi | 35 +++-
>  gcc/testsuite/gcc.dg/Wreturn-mismatch-1.c   | 40 
>  gcc/testsuite/gcc.dg/Wreturn-mismatch-2.c   | 41 
> +
>  gcc/testsuite/gcc.dg/Wreturn-mismatch-3.c   | 40 
>  gcc/testsuite/gcc.dg/Wreturn-mismatch-4.c   | 40 
>  gcc/testsuite/gcc.dg/Wreturn-mismatch-5.c   | 40 
>  gcc/testsuite/gcc.dg/noncompile/pr55976-1.c |  2 +-
>  gcc/testsuite/gcc.dg/noncompile/pr55976-2.c |  2 +-
>  10 files changed, 234 insertions(+), 25 deletions(-)
>
> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
> index 44b9c862c14..4c2ebd08af5 100644
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -1263,6 +1263,10 @@ Wreorder
>  C++ ObjC++ Var(warn_reorder) Warning LangEnabledBy(C++ ObjC++,Wall)
>  Warn when the compiler reorders code.
>
> +Wreturn-mismatch
> +C ObjC Var(warn_return_mismatch) Warning Init(1)
> +Warn whenever void-returning functions return a non-void expressions, or a 
> return expression is missing in a function not returning void.
> +
>  Wreturn-type
>  C ObjC C++ ObjC++ Var(warn_return_type) Warning LangEnabledBy(C ObjC C++ 
> ObjC++,Wall) Init(-1)
>  Warn whenever a function's return type defaults to \"int\" (C), or about 
> inconsistent return types (C++).
> diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
> index 6e044b4afbc..1da622160a3 100644
> --- a/gcc/c/c-typeck.cc
> +++ b/gcc/c/c-typeck.cc
> @@ -11281,17 +11281,10 @@ c_finish_return (location_t loc, tree retval, tree 
> origtype)
>if ((warn_return_type >= 0 || flag_isoc99)
>   && valtype != NULL_TREE && TREE_CODE (valtype) != VOID_TYPE)
> {
> - bool warned_here;
> - if (flag_isoc99)
> -   warned_here = pedwarn
> - (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0,
> -  "% with no value, in function returning non-void");
> - else
> -   warned_here = warning_at
> - (loc, OPT_Wreturn_type,
> -  "% with no value, in function returning non-void");
>   no_warning = true;
> - if (warned_here)
> + if (pedwarn (loc, OPT_Wreturn_mismatch,
> +  "% with no value,"
> +  " in function returning non-void"))
> inform (DECL_SOURCE_LOCATION (current_function_decl),
> "declared here");
> }
> @@ -11302,7 +11295,7 @@ c_finish_return (location_t loc, tree retval, tree 
> origtype)
>bool warned_here;
>if (TREE_CODE (TREE_TYPE (retval)) != VOID_TYPE)
> warned_here = pedwarn
> - (xloc, warn_return_type >= 0 ? OPT_Wreturn_type : 0,
> + (xloc, OPT_Wreturn_mismatch,
>"% with a value, in function returning void");
>else
> warned_here = pedwarn
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 9b5ff457027..c0c155af7cd 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -7338,22 +7338,33 @@ This warning is enabled by @option{-Wall} for C and 
> C++.
>  Do not warn about returning a pointer (or in C++, a reference) to a
>  variable that goes out of scope after the function returns.
>
> +@opindex Wreturn-mismatch
> +@opindex Wno-return-mismatch
> +@item -Wreturn-mismatch
> +Warn about return statements without an expressions in functions which
> +do not return @code{void}.  Also warn about a @code{return} statement
> +with an expression in a function 

Re: Enable top-level recursive 'autoreconf'

[Eric Gallager]

On Thu, Oct 19, 2023 at 6:43 AM Thomas Schwinge  wrote:
>
> Hi!
>
> On 2023-10-19T11:57:33+0200, Andreas Schwab  wrote:
> > On Okt 19 2023, Thomas Schwinge wrote:
> >> On 2023-10-18T15:42:18+0100, R jd <3246251196r...@gmail.com> wrote:
> >>> I guess I can ask, why there is not a recursive approach for configuring
> >>> GCC. e.g. AC_SUBDIRS in the top level?
> >>
> >> ('AC_CONFIG_SUBDIRS' you mean.)  You know, often it just takes someone to
> >> ask the right questions...  ;-)
> >>
> >> What do people think about the attached
> >> "Enable top-level recursive 'autoreconf'"?  Only lightly tested, so far.
> >
> > The top-level files are shared with binutils-gdb, which has a different
> > set of subdirs.
>
> Good point, thanks!  Fortunately, the failure mode for non-existing
> directories is non-fatal (skipped with 'subdirectory [...] not present'
> diagnostic); with my original "Enable top-level recursive 'autoreconf'"
> (also re-attached) applied to Binutils/GDB Git master branch, we get:
>
> $ PATH=[...] autoreconf -v
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal
> autoreconf: configure.ac: tracing
> autoreconf: configure.ac: subdirectory c++tools not present
> autoreconf: configure.ac: subdirectory fixincludes not present
> autoreconf: configure.ac: subdirectory gcc not present
> autoreconf: configure.ac: subdirectory gcc/m2 not present
> autoreconf: configure.ac: subdirectory gnattools not present
> autoreconf: configure.ac: subdirectory gotools not present
> autoreconf: configure.ac: adding subdirectory intl to autoreconf
> autoreconf: Entering directory `intl'
> [...]
> autoreconf: Leaving directory `intl'
> autoreconf: configure.ac: subdirectory libada not present
> autoreconf: configure.ac: subdirectory libatomic not present
> autoreconf: configure.ac: adding subdirectory libbacktrace to autoreconf
> autoreconf: Entering directory `libbacktrace'
> [...]
>
> So we could (a) simply list *all* directories in the shared top-level
> 'configure.ac', or (b) configure GCC vs. other projrcts via a non-shared
> file ('m4_include([config/AC_CONFIG_SUBDIRS.m4])' or similar -- is there
> an established procedure for non-shared top-level files)?  (I don't have
> a strong preference either way.)
>

I'd just like to note that I have GCC bug 103459 open about silencing
warnings from autoreconf:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103459
Although I guess in this case, they're just notices, and not warnings,
so it's probably okay. (-Werror doesn't turn them into errors, does
it?)

> It's just GCC and Binutils/GDB, or are the top-level files also shared
> with additional projects?
>
>
> Grüße
>  Thomas
>
>
> -
> 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] Support g++ 4.8 as a host compiler.

[Eric Gallager]

On Sun, Oct 15, 2023 at 7:43 AM Richard Sandiford
 wrote:
>
> "Roger Sayle"  writes:
> > I'd like to ping my patch for restoring bootstrap using g++ 4.8.5
> > (the system compiler on RHEL 7 and later systems).
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632008.html
> >
> > Note the preprocessor #ifs can be removed; they are only there to document
> > why the union u must have an explicit, empty (but not default) constructor.
> >
> > I completely agree with the various opinions that we might consider
> > upgrading the minimum host compiler for many good reasons (Ada,
> > D, newer C++ features etc.).  It's inevitable that older compilers and
> > systems can't be supported indefinitely.
> >
> > Having said that I don't think that this unintentional trivial breakage,
> > that has a safe one-line work around is sufficient cause (or non-neglible
> > risk or support burden), to inconvenice a large number of GCC users
> > (the impact/disruption to cfarm has already been mentioned).
> >
> > Interestingly, "scl enable devtoolset-XX" to use a newer host compiler,
> > v10 or v11, results in a significant increase (100+) in unexpected failures 
> > I see
> > during mainline regression testing using "make -k check" (on RedHat 7.9).
> > (Older) system compilers, despite their flaws, are selected for their
> > (overall) stability and maturity.
> >
> > If another patch/change hits the compiler next week that reasonably
> > means that 4.8.5 can no longer be supported, so be it, but its an
> > annoying (and unnecessary?) inconvenience in the meantime.
> >
> > Perhaps we should file a Bugzilla PR indicating that the documentation
> > and release notes need updating, if my fix isn't considered acceptable?
> >
> > Why this patch is an trigger issue (that requires significant discussion
> > and deliberation) is somewhat of a mystery.
>
> It seemed like there was considerable support for bumping the minimum
> to beyond 4.8.  I think we should wait until a decision has been made
> before adding more 4.8 workarounds.
>
> Having a conditional explicit constructor is dangerous because it changes
> semantics.  E.g. consider:
>
>   #include 
>
>   union u { int x; };
>   void f(u *ptr) { new(ptr) u; }
>   void g(u *ptr) { new(ptr) u(); }
>
> g(ptr) zeros ptr->x whereas f(ptr) doesn't.  If we add "u() {}" then g()
> does not zero ptr->x.
>
> So if we did add the workaround, it would need to be unconditional,
> like you say.
>
> Thanks,
> Richard

I personally would prefer it if GCC would continue to maintain support
for gcc 4.8 for a host compiler. One of the things I like about GCC is
how it's generally tried to keep support for older host tools for
longer than other projects do, meaning that with GCC, you don't get
stuck on the upgrade treadmill of having to compile a whole string of
consecutive compilers just to be able to compile the latest one like
you have to do with clang. Please just apply Roger's patch; it already
exists and is relatively simple.

Re: [PATCH] Add files to discourage submissions of PRs to the GitHub mirror.

[Eric Gallager]

On Mon, Oct 16, 2023 at 7:58 PM Andrew Pinski  wrote:
>
>
>
> On Mon, Oct 16, 2023, 16:39 Eric Gallager  wrote:
>>
>> Currently there is an unofficial mirror of GCC on GitHub that people
>> sometimes submit pull requests to:
>> https://github.com/gcc-mirror/gcc
>> However, this is not the proper way to contribute to GCC, so that means
>> that someone (usually Jonathan Wakely) has to go through the PRs and
>> manually tell people that they're sending their PRs to the wrong place.
>> One thing that would help mitigate this problem would be files in a
>> special .github directory that GitHub would automatically open when
>> contributors attempt to open a PR, that would then tell them the proper
>> way to contribute instead. This patch attempts to add two such files.
>> They are written in Markdown, which I'm realizing might require some
>> special handling in this repository, since the ".md" extension is also
>> used for GCC's "Machine Description" files here, but I'm not quite sure
>> how to go about handling that. Also note that I adapted these files from
>> equivalent files in the git repository for Git itself:
>> https://github.com/git/git/blob/master/.github/CONTRIBUTING.md
>> https://github.com/git/git/blob/master/.github/PULL_REQUEST_TEMPLATE.md
>> What do people think?
>
>
>
> I think this is a great idea. Is a similar one for opening issues too?
>

One for issues isn't necessary, because the GitHub mirror has never
had issues enabled in the first place, so people already can't open
issues there.

> Thanks,
> Andrew
>
>
>> ChangeLog:
>>
>> * .github/CONTRIBUTING.md: New file.
>> * .github/PULL_REQUEST_TEMPLATE.md: New file.
>> ---
>>  .github/CONTRIBUTING.md  | 18 ++
>>  .github/PULL_REQUEST_TEMPLATE.md |  5 +
>>  2 files changed, 23 insertions(+)
>>  create mode 100644 .github/CONTRIBUTING.md
>>  create mode 100644 .github/PULL_REQUEST_TEMPLATE.md
>>
>> diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
>> new file mode 100644
>> index ..4f7b3abca5f4
>> --- /dev/null
>> +++ b/.github/CONTRIBUTING.md
>> @@ -0,0 +1,18 @@
>> +## Contributing to GCC
>> +
>> +Thanks for taking the time to contribute to GCC! Please be advised that if 
>> you are
>> +viewing this on `github.com`, that the mirror there is unofficial and 
>> unmonitored.
>> +The GCC community does not use `github.com` for their contributions. 
>> Instead, we use
>> +a mailing list (`gcc-patches@gcc.gnu.org`) for code submissions, code
>> +reviews, and bug reports.
>> +
>> +Perhaps one day it will be possible to use 
>> [GitGitGadget](https://gitgitgadget.github.io/) to
>> +conveniently send Pull Requests commits to GCC's mailing list, the way that 
>> the Git project currently allows it to be used to send PRs to their mailing 
>> list, but until that day arrives, please send your patches to the mailing 
>> list manually.
>> +
>> +Please read ["Contributing to GCC"](https://gcc.gnu.org/contribute.html) on 
>> the main GCC website
>> +to learn how the GCC project is managed, and how you can work with it.
>> +In addition, we highly recommend you to read [our guidelines for read-write 
>> Git access](https://gcc.gnu.org/gitwrite.html).
>> +
>> +Or, you can follow the ["Contributing to GCC in 10 easy 
>> steps"](https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps)
>>  section of the ["Getting Started" 
>> page](https://gcc.gnu.org/wiki/GettingStarted) on [the 
>> wiki](https://gcc.gnu.org/wiki) for another example of the contribution 
>> process.
>> +
>> +Your friendly GCC community!
>> diff --git a/.github/PULL_REQUEST_TEMPLATE.md 
>> b/.github/PULL_REQUEST_TEMPLATE.md
>> new file mode 100644
>> index ..6417392c8cf3
>> --- /dev/null
>> +++ b/.github/PULL_REQUEST_TEMPLATE.md
>> @@ -0,0 +1,5 @@
>> +Thanks for taking the time to contribute to GCC! Please be advised that if 
>> you are
>> +viewing this on `github.com`, that the mirror there is unofficial and 
>> unmonitored.
>> +The GCC community does not use `github.com` for their contributions. 
>> Instead, we use
>> +a mailing list (`gcc-patches@gcc.gnu.org`) for code submissions, code 
>> reviews, and
>> +bug reports. Please send patches there instead.

[PATCH] Add files to discourage submissions of PRs to the GitHub mirror.

[Eric Gallager]

Currently there is an unofficial mirror of GCC on GitHub that people
sometimes submit pull requests to:
https://github.com/gcc-mirror/gcc
However, this is not the proper way to contribute to GCC, so that means
that someone (usually Jonathan Wakely) has to go through the PRs and
manually tell people that they're sending their PRs to the wrong place.
One thing that would help mitigate this problem would be files in a
special .github directory that GitHub would automatically open when
contributors attempt to open a PR, that would then tell them the proper
way to contribute instead. This patch attempts to add two such files.
They are written in Markdown, which I'm realizing might require some
special handling in this repository, since the ".md" extension is also
used for GCC's "Machine Description" files here, but I'm not quite sure
how to go about handling that. Also note that I adapted these files from
equivalent files in the git repository for Git itself:
https://github.com/git/git/blob/master/.github/CONTRIBUTING.md
https://github.com/git/git/blob/master/.github/PULL_REQUEST_TEMPLATE.md
What do people think?

ChangeLog:

* .github/CONTRIBUTING.md: New file.
* .github/PULL_REQUEST_TEMPLATE.md: New file.
---
 .github/CONTRIBUTING.md  | 18 ++
 .github/PULL_REQUEST_TEMPLATE.md |  5 +
 2 files changed, 23 insertions(+)
 create mode 100644 .github/CONTRIBUTING.md
 create mode 100644 .github/PULL_REQUEST_TEMPLATE.md

diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
new file mode 100644
index ..4f7b3abca5f4
--- /dev/null
+++ b/.github/CONTRIBUTING.md
@@ -0,0 +1,18 @@
+## Contributing to GCC
+
+Thanks for taking the time to contribute to GCC! Please be advised that if you 
are
+viewing this on `github.com`, that the mirror there is unofficial and 
unmonitored.
+The GCC community does not use `github.com` for their contributions. Instead, 
we use
+a mailing list (`gcc-patches@gcc.gnu.org`) for code submissions, code
+reviews, and bug reports.
+
+Perhaps one day it will be possible to use 
[GitGitGadget](https://gitgitgadget.github.io/) to
+conveniently send Pull Requests commits to GCC's mailing list, the way that 
the Git project currently allows it to be used to send PRs to their mailing 
list, but until that day arrives, please send your patches to the mailing list 
manually.
+
+Please read ["Contributing to GCC"](https://gcc.gnu.org/contribute.html) on 
the main GCC website
+to learn how the GCC project is managed, and how you can work with it.
+In addition, we highly recommend you to read [our guidelines for read-write 
Git access](https://gcc.gnu.org/gitwrite.html).
+
+Or, you can follow the ["Contributing to GCC in 10 easy 
steps"](https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps)
 section of the ["Getting Started" 
page](https://gcc.gnu.org/wiki/GettingStarted) on [the 
wiki](https://gcc.gnu.org/wiki) for another example of the contribution process.
+
+Your friendly GCC community!
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
new file mode 100644
index ..6417392c8cf3
--- /dev/null
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -0,0 +1,5 @@
+Thanks for taking the time to contribute to GCC! Please be advised that if you 
are
+viewing this on `github.com`, that the mirror there is unofficial and 
unmonitored.
+The GCC community does not use `github.com` for their contributions. Instead, 
we use
+a mailing list (`gcc-patches@gcc.gnu.org`) for code submissions, code reviews, 
and
+bug reports. Please send patches there instead.

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

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)

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

[Eric Gallager]

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

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

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: [PATCH] Remove non-ANSI C path in ansidecl.h.

[Eric Gallager]

On Thu, May 5, 2022 at 8:27 AM Richard Biener via Gcc-patches
 wrote:
>
> On Thu, May 5, 2022 at 2:19 PM Martin Liška  wrote:
> >
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
> >
> > Ready to be installed?
> > Thanks,
> > Martin
> >
> > include/ChangeLog:
> >
> > * ansidecl.h (PTR): Remove Not ANCI C part.
> > ---
> >  include/ansidecl.h | 16 +---
> >  1 file changed, 1 insertion(+), 15 deletions(-)
> >
> > diff --git a/include/ansidecl.h b/include/ansidecl.h
> > index 4275c9b9cbd..f42c6afc7e9 100644
> > --- a/include/ansidecl.h
> > +++ b/include/ansidecl.h
> > @@ -89,21 +89,7 @@ So instead we use the macro below and test it against 
> > specific values.  */
> >  # endif
> >  #endif
> >
> > -#else  /* Not ANSI C.  */
> > -
> > -#define PTRchar *
> > -
> > -/* some systems define these in header files for non-ansi mode */
> > -#undef const
> > -#undef volatile
> > -#undef signed
> > -#undef inline
> > -#define const
> > -#define volatile
> > -#define signed
> > -#define inline
> > -
> > -#endif /* ANSI C.  */
>
> You'd have to ask the sourceware side as well (binutils), but for sure
> either the
> guarding #if should be removed or the #else path should contain an #error.

Maybe just make it a #warning for one release, and then if no one
complains, turn it into an #error in the following release?

>
> Richard.
>
> > +#endif
> >
> >  /* Define macros for some gcc attributes.  This permits us to use the
> > macros freely, and know that they will come into play for the
> > --
> > 2.36.0
> >

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
<https://gcc.gnu.org/wiki/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
> >