[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e091ed53-d5d0-101d-92a6-a215350e482e@arm.com>
Date: Wed, 7 Sep 2022 09:52:48 +0530
From: Anshuman Khandual <anshuman.khandual@....com>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the perf tree
On 9/7/22 08:30, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 7 Sep 2022 08:01:34 +0530 Anshuman Khandual <anshuman.khandual@....com> wrote:
>>
>> On 9/7/22 00:35, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> On Wed, 31 Aug 2022 08:34:52 +1000 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>>>>
>>>> After merging the perf tree, today's linux-next build (native perf)
>>>> failed like this:
>>>>
>>>> In file included from /usr/include/stdio.h:866,
>>>> from /home/sfr/next/next/tools/perf/util/branch.h:9,
>>>> from util/branch.c:2:
>>>> In function 'fprintf',
>>>> inlined from 'branch_type_stat_display' at util/branch.c:152:4:
>>>> /usr/include/powerpc64le-linux-gnu/bits/stdio2.h:105:10: error: '%8s' directive argument is null [-Werror=format-overflow=]
>>>> 105 | return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt,
>>>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> 106 | __va_arg_pack ());
>>>> | ~~~~~~~~~~~~~~~~~
>>>> cc1: all warnings being treated as errors
>>>>
>>>> Presumably caused by commit
>>>>
>>>> 9781e500dcb8 ("perf branch: Extend branch type classification")
>>>>
>>>> "native" here is PowerPC64 LE.
>>>> $ gcc --version
>>>> gcc (Debian 11.2.0-10) 11.2.0
>>>>
>>>> I have used the perf tree from next-20220830 for today.
>>>
>>> I am still seeing this build failure.
>>
>> But did you apply the fix patch from Arnaldo that removes -Wno-format-overflow
>> compiler option for the file util/branch.c ?
>>
>> https://lore.kernel.org/all/YxJBh3wvAGol+Ekq@kernel.org/
>
> No, I expected a fix to be in the perf tree ...
>
> Also note that the following fixes the problem for me:
>
> diff --git a/tools/perf/util/branch.c b/tools/perf/util/branch.c
> index d40776c44b06..b7b898f2872e 100644
> --- a/tools/perf/util/branch.c
> +++ b/tools/perf/util/branch.c
> @@ -88,7 +88,8 @@ const char *branch_type_name(int type)
> "ERET",
> "IRQ",
> "SERROR",
> - "NO_TX"
> + "NO_TX",
> + ""
> };
>
> if (type >= 0 && type < PERF_BR_MAX)
This looks right, makes sense.
>
>
> PERF_BR_MAX has been increased by one (when PERF_BR_EXTEND_ABI was
> added), but a new string has not been added to the array ...
Right, even though new branch_new_names[] array gets queried on when type
value is PERF_BR_EXTEND_ABI, branch_names[] should still contain an empty
string "" just to match the now incremented PERF_BR_MAX which extends the
array size as well. I guess the compiler detects this mismatch here and
just complains about it.
Hello Arnaldo,
As adding empty string to the array solves the build problem, I guess we
should fold this fix instead, rather than trying to drop the compiler
option itself, as discussed earlier.
The above fix should be folded into the following commit
9781e500dcb8 ("perf branch: Extend branch type classification")
in the following perf tree - branch.
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git (perf/core)
- Anshuman
Powered by blists - more mailing lists