From: Kees Cook <keescook@chromium.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Randy Dunlap <rdunlap@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Nathan Chancellor <nathan@kernel.org>
Subject: Re: linux-next: Tree for Aug 20 (Wno-alloc-size-larger-than)
Date: Tue, 24 Aug 2021 18:59:30 -0700 [thread overview]
Message-ID: <202108241858.63C1FBC1@keescook> (raw)
In-Reply-To: <20210824115859.187f272f@canb.auug.org.au>
On Tue, Aug 24, 2021 at 11:58:59AM +1000, Stephen Rothwell wrote:
> Hi Randy,
>
> On Mon, 23 Aug 2021 18:24:44 -0700 Randy Dunlap <rdunlap@infradead.org> wrote:
> >
> > This is just weird. What I am seeing is that for every source file
> > where gcc emits a warning: it then follows that up with this
> > >> cc1: warning: unrecognized command line option '-Wno-alloc-size-larger-than'
>
> I see the same, as well as:
>
> <stdin>:1515:2: warning: #warning syscall clone3 not implemented [-Wcpp]
> cc1: warning: unrecognized command line option '-Wno-alloc-size-larger-than'
>
> But only on my gcc 7.3.1 builds (the rest are gcc 10).
>
> > Smells like a gcc bug to me.
>
> Yes
>
> Also noted here: https://github.com/DynamoRIO/drmemory/issues/2099 (second comment)
Wow, this is really weird. Okay, thanks for the pointers. I'll keep
investigating. I may need to version-limit the use of __alloc_size,
though I'd rather not. We've been able to depend on has_builtin() nicely
for a while now. :P
--
Kees Cook
next prev parent reply other threads:[~2021-08-25 1:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-20 9:26 linux-next: Tree for Aug 20 Stephen Rothwell
2021-08-20 21:54 ` linux-next: Tree for Aug 20 (Wno-alloc-size-larger-than) Randy Dunlap
2021-08-21 5:48 ` Kees Cook
2021-08-21 19:09 ` Randy Dunlap
2021-08-23 10:37 ` Stephen Rothwell
2021-08-24 1:24 ` Randy Dunlap
2021-08-24 1:58 ` Stephen Rothwell
2021-08-25 1:59 ` Kees Cook [this message]
2021-08-25 17:04 ` Kees Cook
2021-08-25 17:49 ` Randy Dunlap
2021-08-26 3:54 ` Kees Cook
2021-08-26 5:10 ` Randy Dunlap
2021-08-26 5:23 ` Kees Cook
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=202108241858.63C1FBC1@keescook \
--to=keescook@chromium.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=nathan@kernel.org \
--cc=rdunlap@infradead.org \
--cc=sfr@canb.auug.org.au \
/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.