From: Petr Lautrbach <plautrba@redhat.com>
To: "Roberts\, William C" <william.c.roberts@intel.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
"selinux\@vger.kernel.org" <selinux@vger.kernel.org>,
Ondrej Mosnacek <omosnace@redhat.com>
Subject: Re: gcc 9.0.0 build issues
Date: Tue, 12 Feb 2019 17:37:36 +0100 [thread overview]
Message-ID: <pjdbm3hx8rz.fsf@redhat.com> (raw)
In-Reply-To: <476DC76E7D1DF2438D32BFADF679FC5649CE8B71@ORSMSX101.amr.corp.intel.com> (William C. Roberts's message of "Fri, 8 Feb 2019 19:40:35 +0000")
"Roberts, William C" <william.c.roberts@intel.com> writes:
>> -----Original Message-----
>> From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
>> Sent: Thursday, February 7, 2019 10:17 AM
>> To: Roberts, William C <william.c.roberts@intel.com>; Petr Lautrbach
>> <plautrba@redhat.com>; selinux@vger.kernel.org
>> Cc: Ondrej Mosnacek <omosnace@redhat.com>
>> Subject: Re: gcc 9.0.0 build issues
>>
>> On 2/7/19 12:52 PM, Roberts, William C wrote:
>> >
>> >
>> >> -----Original Message-----
>> >> From: Petr Lautrbach [mailto:plautrba@redhat.com]
>> >> Sent: Thursday, February 7, 2019 4:40 AM
>> >> To: selinux@vger.kernel.org
>> >> Cc: Petr Lautrbach <plautrba@redhat.com>; Roberts, William C
>> >> <william.c.roberts@intel.com>; Ondrej Mosnacek <omosnace@redhat.com>
>> >> Subject: Re: gcc 9.0.0 build issues
>> >>
>> >>
>> >> Ondrej Mosnacek <omosnace@redhat.com> writes:
>> >>
>> >>> On Fri, Feb 1, 2019 at 8:36 PM Petr Lautrbach <plautrba@redhat.com>
>> >>> wrote:
>> >>>> gcc-9.0.0-0.3.fc30.x86_64 from Fedora Rawhide:
>> >>>>
>> >>>> gcc version 9.0.0 20190119 (Red Hat 9.0.0-0.3) (GCC)
>> >>>>
>> >> ...
>> >>>> When libselinux is built separately, other CFLAGS is used:
>> >>>>
>> >>>> $ cd libselinux
>> >>>>
>> >>>> $ make DESTDIR=~/obj install install-pywrap ...
>> >>>>
>> >>>> make[1]: Entering directory
>> >>>> '/home/build/SELinuxProject-selinux/libselinux/src'
>> >>>>
>> >>>> cc -O -Wall -W -Wundef -Wformat-y2k -Wformat-security -Winit-self
>> >>>> -Wmissing-include-dirs -Wunused -Wunknown-pragmas -Wstrict-aliasing
>> >>>> -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align
>> >>>> -Wwrite-strings -Waggregate-return -Wstrict-prototypes
>> >>>> -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations
>> >>>> -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls
>> >>>> -Wnested-externs -Winline -Winvalid-pch -Wvolatile-register-var
>> >>>> -Wdisabled-optimization -Wbuiltin-macro-redefined -Wattributes
>> >>>> -Wmultichar -Wdeprecated-declarations -Wdiv-by-zero
>> >>>> -Wdouble-promotion -Wendif-labels -Wextra -Wformat-extra-args
>> >>>> -Wformat-zero-length -Wformat=2 -Wmultichar -Woverflow
>> >>>> -Wpointer-to-int-cast -Wpragmas -Wno-missing-field-initializers
>> >>>> -Wno-sign-compare -Wno-format-nonliteral
>> >>>> -Wframe-larger-than=32768
>> >>>> -fstack-protector-all --param=ssp-buffer-size=4 -fexceptions
>> >>>> -fasynchronous-unwind-tables -fdiagnostics-show-option
>> >>>> -funit-at-a-time -Werror -Wno-aggregate-return -Wno-redundant-decls
>> >>>> -fipa-pure-const -Wlogical-op -Wpacked-bitfield-compat -Wsync-nand
>> >>>> -Wcoverage-mismatch -Wcpp -Wformat-contains-nul -Wnormalized=nfc
>> >>>> -Wsuggest-attribute=const -Wsuggest-attribute=noreturn
>> >>>> -Wsuggest-attribute=pure -Wtrampolines -Wjump-misses-init
>> >>>> -Wno-suggest-attribute=pure -Wno-suggest-attribute=const
>> >>>> -U_FORTIFY_SOURCE
>> >>>> -D_FORTIFY_SOURCE=2
>> >>>> -Wstrict-overflow=5 -I../include -D_GNU_SOURCE
>> >>>> -DNO_ANDROID_BACKEND -c -o booleans.o booleans.c
>> >>>> booleans.c: In function ‘security_get_boolean_names’:
>> >>>> booleans.c:39:5: error: assuming signed overflow does not occur
>> >>>> when changing X +- C1 cmp C2 to X cmp C2 -+ C1 [-Werror=strict-overflow]
>> >>>> 39 | int security_get_boolean_names(char ***names, int *len)
>> >>>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~
>> >>>> cc1: all warnings being treated as errors
>> >>>
>> >>> This one is really weird... Perhaps a bug in GCC? At the very least
>> >>> the warning message and source code location are super confusing,
>> >>> which is a bug on its own...
>> >>
>> >> It's detected only with -Wstrict-overflow=3 and higher. Makefile in
>> >> libselinux uses level 5 which was added by commit
>> >> 9fe430345 ("Makefile: add -Wstrict-overflow=5 to CFLAGS)
>> >>
>> >> The problem code is on lines 84 and 85 in
>> >> libselinux/src/booleans.c:
>> >>
>> >> 84: for (--i; i >= 0; --i)
>> >> 85: free(n[i]);
>> >>
>> >>
>> >> It could be suppressed by something like this:
>> >>
>> >> --- a/libselinux/src/booleans.c
>> >> +++ b/libselinux/src/booleans.c
>> >> @@ -39,7 +39,7 @@ static int filename_select(const struct dirent
>> >> *d)
>> >> int security_get_boolean_names(char ***names, int *len) {
>> >> char path[PATH_MAX];
>> >> - int i, rc;
>> >> + int i, j, rc;
>> >> struct dirent **namelist;
>> >> char **n;
>> >>
>> >> @@ -81,8 +81,8 @@ int security_get_boolean_names(char ***names, int
>> *len)
>> >> free(namelist);
>> >> return rc;
>> >> bad_freen:
>> >> - for (--i; i >= 0; --i)
>> >> - free(n[i]);
>> >> + for (j = 0; j < i; j++)
>> >> + free(n[j]);
>> >> free(n);
>> >> bad:
>> >> goto out;
>> >>
>> >>
>> >> William, what would you consider to be the right fix in this case?
>> >
>> > The previous code looks correct IMO, I can't see an actual problem.
>> > Looks like GCC complaining incorrectly or were missing something. In
>> > the case of gcc Incorrectly complaining I usually take a course of
>> > action to work around it, but Im not sure how other maintainers feel about that
>> @sds anything?
>>
>> AFAICS, the code is correct as is. Not a fan of rewriting code to appease overly
>> zealous compilers...
>>
>
> So I looked at filing a bug with GCC, and one thing that helps it get looked at is sample code
> to trigger the problem. I'm not even seeing a GCC 9 release, so I am assuming it's in a dev
> mode?
>
> Since you have it running could you see if you can re-produce the error in a snippet and file the bug?
>
> I would also diff the object file with -frwapv to see if it is producing different code for that loop.
>
> Bill
Fedora gcc is built with
--with-bugurl=http://bugzilla.redhat.com/bugzilla therefore I filed bug
there: https://bugzilla.redhat.com/show_bug.cgi?id=1676607
Petr
next prev parent reply other threads:[~2019-02-12 16:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-01 19:34 gcc 9.0.0 build issues Petr Lautrbach
2019-02-01 20:24 ` Ondrej Mosnacek
2019-02-07 12:40 ` Petr Lautrbach
2019-02-07 17:52 ` Roberts, William C
2019-02-07 18:17 ` Stephen Smalley
2019-02-07 18:18 ` Roberts, William C
2019-02-07 18:20 ` Stephen Smalley
2019-02-07 18:22 ` Roberts, William C
2019-02-08 19:40 ` Roberts, William C
2019-02-08 20:10 ` Ondrej Mosnacek
2019-02-12 16:37 ` Petr Lautrbach [this message]
2019-02-07 15:32 ` Ondrej Mosnacek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pjdbm3hx8rz.fsf@redhat.com \
--to=plautrba@redhat.com \
--cc=omosnace@redhat.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@vger.kernel.org \
--cc=william.c.roberts@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.