Discussion:
Emacs release branch warnings with GCC 8
(too old to reply)
Paul Eggert
2018-04-30 17:12:36 UTC
Permalink
The emacs-26 branch has some warnings when compiled on Fedora 28, which
is scheduled for release next week; see attached. This is because Fedora
28 uses GCC 8.0.1, and when --enable-gcc-warnings is used (which is the
default in a build from Git), GCC 8 issues some warnings that GCC 7 does
not. I've patched the master to fix this problem in commits
2b9ab8c8fba849da8bf2aa45e65b122bb937a6b3 and
8c3215e7a47e3caaa005bf573765ed63e0739b89, and could backport these
patches (or a subset) to emacs-26 if there's interest.

Only one of the warnings indicates a real bug, one in emacsclient that
could cause undefined behavior. On the other hand, if we don't pacify
GCC 8 now we're likely to get bug reports about the warnings for quite
some time, and it might be less work for everybody involved if we squash
the warnings now.
Eli Zaretskii
2018-04-30 19:38:38 UTC
Permalink
Date: Mon, 30 Apr 2018 10:12:36 -0700
The emacs-26 branch has some warnings when compiled on Fedora 28, which
is scheduled for release next week; see attached. This is because Fedora
28 uses GCC 8.0.1, and when --enable-gcc-warnings is used (which is the
default in a build from Git), GCC 8 issues some warnings that GCC 7 does
not.
But a release tarball is not built with --enable-gcc-warnings by
default, right?
I've patched the master to fix this problem in commits
2b9ab8c8fba849da8bf2aa45e65b122bb937a6b3 and
8c3215e7a47e3caaa005bf573765ed63e0739b89, and could backport these
patches (or a subset) to emacs-26 if there's interest.
I'm okay with the first one, but I don't understand how the warnings
you've shown are related to the ATTRIBUTE_MALLOC changes in the second
commit. If those are not necessary to shut up warnings, I'd prefer
not to backport those, as the attribute stuff can be a potential
portability problem.

Thanks.
Paul Eggert
2018-04-30 19:52:59 UTC
Permalink
Post by Eli Zaretskii
But a release tarball is not built with --enable-gcc-warnings by
default, right?
Right. This is about people who build from a release tarball with
--enable-gcc-warnings, and about people who build from Git (the latter
appear to be a growing number....).
Post by Eli Zaretskii
Post by Paul Eggert
I've patched the master to fix this problem in commits
2b9ab8c8fba849da8bf2aa45e65b122bb937a6b3 and
8c3215e7a47e3caaa005bf573765ed63e0739b89, and could backport these
patches (or a subset) to emacs-26 if there's interest.
I'm okay with the first one, but I don't understand how the warnings
you've shown are related to the ATTRIBUTE_MALLOC changes in the second
commit.
The first commit enables -Wsuggest-attribute=malloc, and the
ATTRIBUTE_MALLOC changes in the second commit then pacifies GCC in that
area. We could change the first commit to not enable
-Wsuggest-attribute=malloc and this would simplify the second commit,
though we'd then be differing from Gnulib in the first commit.
Eli Zaretskii
2018-04-30 19:58:26 UTC
Permalink
Date: Mon, 30 Apr 2018 12:52:59 -0700
The first commit enables -Wsuggest-attribute=malloc, and the
ATTRIBUTE_MALLOC changes in the second commit then pacifies GCC in that
area. We could change the first commit to not enable
-Wsuggest-attribute=malloc and this would simplify the second commit,
though we'd then be differing from Gnulib in the first commit.
I'd prefer to leave -Wsuggest-attribute=malloc out on the release
branch, for now. We could add that after 26.1 is released, hopefully
soon.

Thanks.
Paul Eggert
2018-05-01 00:22:16 UTC
Permalink
Post by Eli Zaretskii
I'd prefer to leave -Wsuggest-attribute=malloc out on the release
branch, for now.
OK, I installed the attached backport into the emacs-26 branch; it does
the minimum to silence the diagnostics, without adding the new GCC 8
warning options.

Loading...