From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
clang-built-linux@googlegroups.com,
Nathan Chancellor <natechancellor@gmail.com>,
linux-s390 <linux-s390@vger.kernel.org>,
Vasily Gorbik <gor@linux.ibm.com>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Philipp Rudo <prudo@linux.ibm.com>,
Hendrik Brueckner <brueckner@linux.ibm.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] s390: boot, purgatory: pass $(CLANG_FLAGS) where needed
Date: Mon, 15 Apr 2019 08:32:34 +0200 [thread overview]
Message-ID: <20190415083234.7f05254b@mschwideX1> (raw)
In-Reply-To: <CAKwvOdmdUv3pOGdsJCf5HG3KGPfq8TJHY0523jPD=etJwuES7g@mail.gmail.com>
On Thu, 11 Apr 2019 11:08:31 -0700
Nick Desaulniers <ndesaulniers@google.com> wrote:
> On Thu, Apr 11, 2019 at 1:52 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Thu, Apr 11, 2019 at 12:14 AM 'Nick Desaulniers' via Clang Built
> > Linux <clang-built-linux@googlegroups.com> wrote:
> > > On Wed, Apr 10, 2019 at 1:13 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > >
> > > > The purgatory and boot Makefiles do not inherit the original cflags,
> > > > so clang falls back to the default target architecture when building it,
> > > > typically this would be x86 when cross-compiling.
> > > >
> > > > Add $(CLANG_FLAGS) everywhere so we pass the correct --target=s390x-linux
> > > > option when cross-compiling.
> > > >
> > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > > ---
> > > > arch/s390/Makefile | 5 +++--
> > > > arch/s390/purgatory/Makefile | 1 +
> > > > 2 files changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/arch/s390/Makefile b/arch/s390/Makefile
> > > > index 9c079a506325..443990791099 100644
> > > > --- a/arch/s390/Makefile
> > > > +++ b/arch/s390/Makefile
> > > > @@ -17,12 +17,13 @@ KBUILD_CFLAGS_MODULE += -fPIC
> > > > KBUILD_AFLAGS += -m64
> > > > KBUILD_CFLAGS += -m64
> > > > aflags_dwarf := -Wa,-gdwarf-2
> > > > -KBUILD_AFLAGS_DECOMPRESSOR := -m64 -D__ASSEMBLY__
> > > > +KBUILD_AFLAGS_DECOMPRESSOR := $(CLANG_FLAGS) -m64 -D__ASSEMBLY__
> > > > KBUILD_AFLAGS_DECOMPRESSOR += $(if $(CONFIG_DEBUG_INFO),$(aflags_dwarf))
> > > > -KBUILD_CFLAGS_DECOMPRESSOR := -m64 -O2
> > > > +KBUILD_CFLAGS_DECOMPRESSOR := $(CLANG_FLAGS) -m64 -O2
> > > > KBUILD_CFLAGS_DECOMPRESSOR += -DDISABLE_BRANCH_PROFILING -D__NO_FORTIFY
> > > > KBUILD_CFLAGS_DECOMPRESSOR += -fno-delete-null-pointer-checks -msoft-float
> > > > KBUILD_CFLAGS_DECOMPRESSOR += -fno-asynchronous-unwind-tables
> > >
> > > Thanks for the respin with Nathan's suggestion.
> > >
> > > > +KBUILD_CFLAGS_DECOMPRESSOR += $(call cc-disable-warning,pointer-sign)
> > >
> > > What's up with this ^ ? Seems like the top level sets it (without
> > > cc-disable-warning :( ), but then KBUILD_CFLAGS_DECOMPRESSOR discards
> > > it. Does Clang actually flag code in this arch (that GCC doesn't)?
> >
> > Oops, that should have been a separate patch.
> >
> > I think what happens is that clang warns more aggressively about pointer sign
> > bugs than gcc in some cases, and some of those cases happen in s390
> > header files that are included by both the kernel and the decompressor.
> >
> > The full warning log without this change is rather long, see
> > https://pastebin.com/KG9xaTNB
>
> From this link, it looks like the definitions of:
> __atomic64_or
> __atomic64_and
> __atomic64_xor
> and their *_barrier variants are problematic. I think converting
> those to use unsigned long is the way to go. Shouldn't you be doing
> bitwise ops on unsigned types anyways?
These functions follow the type of atomic64_t which is a "long" wrapped
in a structure. We do not want to change that to unsigned long, are we?
Then having some of the functions operate on "long" and others on
"unsigned long" seem odd.
> The warnings with __atomic64_add are tougher to read/understand since
> at that point the log lines look like they start to mix together.
>
> >
> > I also tried patching the code to avoid the warnings, but I'm not entirely
> > happy with that result either, see
> > https://pastebin.com/pSMz5eZA
>
> That's no terrible, IMO, particularly with the change I suggest above.
That is not too bad, the only change I do not like is the s/u8/char/ in
struct ipl_block_fcp.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
next prev parent reply other threads:[~2019-04-15 6:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-10 20:12 [PATCH 1/2] s390: only build for new CPUs with clang Arnd Bergmann
2019-04-10 20:12 ` [PATCH 2/2] s390: boot, purgatory: pass $(CLANG_FLAGS) where needed Arnd Bergmann
2019-04-10 22:14 ` Nick Desaulniers
2019-04-11 8:52 ` Arnd Bergmann
2019-04-11 18:08 ` Nick Desaulniers
2019-04-15 6:32 ` Martin Schwidefsky [this message]
2019-04-10 22:20 ` [PATCH 1/2] s390: only build for new CPUs with clang Nick Desaulniers
2019-04-11 10:18 ` Arnd Bergmann
2019-04-11 17:46 ` Nick Desaulniers
2019-04-11 6:23 ` Heiko Carstens
2019-04-11 10:19 ` Arnd Bergmann
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=20190415083234.7f05254b@mschwideX1 \
--to=schwidefsky@de.ibm.com \
--cc=arnd@arndb.de \
--cc=brueckner@linux.ibm.com \
--cc=clang-built-linux@googlegroups.com \
--cc=gor@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=prudo@linux.ibm.com \
--cc=yamada.masahiro@socionext.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.