linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: linux-next: build failure after merge of the perf tree
Date: Wed, 7 Sep 2022 09:52:48 +0530	[thread overview]
Message-ID: <e091ed53-d5d0-101d-92a6-a215350e482e@arm.com> (raw)
In-Reply-To: <20220907130011.32818436@canb.auug.org.au>



On 9/7/22 08:30, Stephen Rothwell wrote:
> Hi all,
> 
> On Wed, 7 Sep 2022 08:01:34 +0530 Anshuman Khandual <anshuman.khandual@arm.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@canb.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

  reply	other threads:[~2022-09-07  4:22 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30 22:34 linux-next: build failure after merge of the perf tree Stephen Rothwell
2022-09-01  5:11 ` Anshuman Khandual
2022-09-06 19:05 ` Stephen Rothwell
2022-09-07  2:31   ` Anshuman Khandual
2022-09-07  3:00     ` Stephen Rothwell
2022-09-07  4:22       ` Anshuman Khandual [this message]
2022-09-08 15:21         ` Arnaldo Carvalho de Melo
  -- strict thread matches above, loose matches on Subject: below --
2024-04-01 22:41 Stephen Rothwell
2024-04-02 20:17 ` Arnaldo Carvalho de Melo
2024-04-12 15:22 ` Arnaldo Carvalho de Melo
2024-04-13  2:43   ` Stephen Rothwell
2024-03-21 21:41 Stephen Rothwell
2024-03-21 23:18 ` Arnaldo Carvalho de Melo
2024-03-21 23:19   ` Arnaldo Carvalho de Melo
2024-03-21 23:32     ` Stephen Rothwell
2024-03-22  2:13       ` Stephen Rothwell
2024-03-22 14:32         ` Arnaldo Carvalho de Melo
2024-03-21 23:36   ` Stephen Rothwell
2024-03-21 23:40     ` arnaldo.melo
2024-03-21 23:48     ` Arnaldo Carvalho de Melo
2024-02-21 23:06 Stephen Rothwell
2024-02-23 19:50 ` Arnaldo Carvalho de Melo
2024-02-06 23:40 Stephen Rothwell
2024-02-07  0:02 ` Ian Rogers
2023-10-24 23:26 Stephen Rothwell
2023-10-25  0:34 ` Namhyung Kim
2023-05-29 23:05 Stephen Rothwell
2023-05-30  2:16 ` Ian Rogers
2023-03-16 22:50 Stephen Rothwell
2023-03-16 23:11 ` Arnaldo Carvalho de Melo
2023-03-16 23:55   ` Stephen Rothwell
2023-03-17  3:23     ` Ian Rogers
2023-03-21 21:39 ` Stephen Rothwell
2023-03-22 18:37   ` Ian Rogers
2023-03-22 22:54     ` Stephen Rothwell
2023-03-23 13:27       ` Arnaldo Carvalho de Melo
2023-03-27 20:31         ` Ian Rogers
2023-03-28  1:33         ` Stephen Rothwell
2023-03-28 19:47           ` Arnaldo Carvalho de Melo
2023-03-28 23:06             ` Stephen Rothwell
2023-03-29 12:28               ` Arnaldo Carvalho de Melo
2023-04-03  5:15                 ` Stephen Rothwell
2022-07-20 23:05 Stephen Rothwell
2022-07-21  2:35 ` Ian Rogers
2022-07-21  3:55   ` Stephen Rothwell
2022-07-21  5:33     ` Ian Rogers
2022-01-05 22:19 Stephen Rothwell
2022-01-07  8:58 ` kajoljain
2022-01-11 21:45   ` Stephen Rothwell
2022-01-11 22:01     ` Arnaldo Carvalho de Melo
2022-01-12  5:30       ` kajoljain
2022-01-12  6:16       ` Stephen Rothwell
2022-01-14 12:03       ` Michael Ellerman

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=e091ed53-d5d0-101d-92a6-a215350e482e@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=arnaldo.melo@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).