[PATCH] ASoC: Intel: avs: replace strcmp with sysfs_streq

[PATCH] ASoC: Intel: avs: replace strcmp with sysfs_streq

[Brahmajit Das]

allmodconfig failes to build with GCC 16 with the following build error

sound/soc/intel/avs/path.c:137:38: error: ‘strcmp’ reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
  137 |         return id->id == id2->id && !strcmp(id->tplg_name, id2->tplg_name);
      |                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ‘avs_condpaths_walk’: events 1-3
  137 |         return id->id == id2->id && !strcmp(id->tplg_name, id2->tplg_name);
      |                ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                  |   |
      |                                  |   (3) warning happens here
      |                                  (1) when the condition is evaluated to true
......
  155 |         if (id->id != path->template->owner->id ||
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                 |
      |                                                 (2) when the condition is evaluated to false
  156 |             strcmp(id->tplg_name, path->template->owner->owner->name))
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from sound/soc/intel/avs/path.h:14,
                 from sound/soc/intel/avs/path.c:15:
sound/soc/intel/avs/topology.h: In function ‘avs_condpaths_walk’:
sound/soc/intel/avs/topology.h:152:13: note: at offset 4 into source object ‘id’ of size 4
  152 |         u32 id;
      |             ^~

Using the sysfs_streq as an alternative to strcmp helps getting around
this build failure.
Please also refer
https://docs.kernel.org/core-api/kernel-api.html#c.__sysfs_match_string

Signed-off-by: Brahmajit Das <listout@listout.xyz>
---
There are other instances of strcmp in the file, which I've not touched
since I'm not sure if they need to replaced and compiler specifically
complained about this instance only.

The idea about using sysfs_streq comes from the kernel documentations
about __sysfs_match_string where in the description it is mentioned
"Uses sysfs_streq instead of strcmp for matching."
---
 sound/soc/intel/avs/path.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/intel/avs/path.c b/sound/soc/intel/avs/path.c
index 7aa20fcf1a33..0c66c8bb2f89 100644
--- a/sound/soc/intel/avs/path.c
+++ b/sound/soc/intel/avs/path.c
@@ -134,7 +134,7 @@ static struct avs_tplg_path *avs_condpath_find_variant(struct avs_dev *adev,
 static bool avs_tplg_path_template_id_equal(struct avs_tplg_path_template_id *id,
 					    struct avs_tplg_path_template_id *id2)
 {
-	return id->id == id2->id && !strcmp(id->tplg_name, id2->tplg_name);
+	return id->id == id2->id && !sysfs_streq(id->tplg_name, id2->tplg_name);
 }
 
 static struct avs_path *avs_condpath_find_match(struct avs_dev *adev,
-- 
2.52.0

Re: [PATCH] ASoC: Intel: avs: replace strcmp with sysfs_streq

[Mark Brown]

On Mon, 22 Dec 2025 00:25:31 +0530, Brahmajit Das wrote:
> allmodconfig failes to build with GCC 16 with the following build error
> 
> sound/soc/intel/avs/path.c:137:38: error: ‘strcmp’ reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
>   137 |         return id->id == id2->id && !strcmp(id->tplg_name, id2->tplg_name);
>       |                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   ‘avs_condpaths_walk’: events 1-3
>   137 |         return id->id == id2->id && !strcmp(id->tplg_name, id2->tplg_name);
>       |                ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       |                                  |   |
>       |                                  |   (3) warning happens here
>       |                                  (1) when the condition is evaluated to true
> ......
>   155 |         if (id->id != path->template->owner->id ||
>       |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       |                                                 |
>       |                                                 (2) when the condition is evaluated to false
>   156 |             strcmp(id->tplg_name, path->template->owner->owner->name))
>       |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from sound/soc/intel/avs/path.h:14,
>                  from sound/soc/intel/avs/path.c:15:
> sound/soc/intel/avs/topology.h: In function ‘avs_condpaths_walk’:
> sound/soc/intel/avs/topology.h:152:13: note: at offset 4 into source object ‘id’ of size 4
>   152 |         u32 id;
>       |             ^~
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: Intel: avs: replace strcmp with sysfs_streq
      commit: 45e9066f3a487e9e26b842644364d045af054775

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Re: [PATCH] ASoC: Intel: avs: replace strcmp with sysfs_streq

[Amadeusz Sławiński]

On Tue, 23 Dec 2025 17:07:04 +0000
Mark Brown <broonie@kernel.org> wrote:

> On Mon, 22 Dec 2025 00:25:31 +0530, Brahmajit Das wrote:
> > allmodconfig failes to build with GCC 16 with the following build error
> > 
> > sound/soc/intel/avs/path.c:137:38: error: ‘strcmp’ reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
> >   137 |         return id->id == id2->id && !strcmp(id->tplg_name, id2->tplg_name);
> >       |                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >   ‘avs_condpaths_walk’: events 1-3
> >   137 |         return id->id == id2->id && !strcmp(id->tplg_name, id2->tplg_name);
> >       |                ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >       |                                  |   |
> >       |                                  |   (3) warning happens here
> >       |                                  (1) when the condition is evaluated to true
> > ......
> >   155 |         if (id->id != path->template->owner->id ||
> >       |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >       |                                                 |
> >       |                                                 (2) when the condition is evaluated to false
> >   156 |             strcmp(id->tplg_name, path->template->owner->owner->name))
> >       |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > In file included from sound/soc/intel/avs/path.h:14,
> >                  from sound/soc/intel/avs/path.c:15:
> > sound/soc/intel/avs/topology.h: In function ‘avs_condpaths_walk’:
> > sound/soc/intel/avs/topology.h:152:13: note: at offset 4 into source object ‘id’ of size 4
> >   152 |         u32 id;
> >       |             ^~
> > 
> > [...]  
> 
> Applied to
> 

Missed this patch and it got applied...

Anyway above log seems bit weird, as this struct should be well defined:
struct avs_tplg_path_template_id {
	u32 id;
	char tplg_name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN];
};
are you sure that SNDRV_CTL_ELEM_ID_NAME_MAXLEN didn't somehow end up
being 0? As that would be a real problem.

sysfs_streq is similar to strcmp, but with different order of checks so
it will just mask an issue, if there really is one. And reading its
description I don't think it should be used in this case.

Can you instead try reverting it and hardcoding value in struct like:
struct avs_tplg_path_template_id {
	u32 id;
	char tplg_name[44];
};
to see if the error is gone?

Re: [PATCH] ASoC: Intel: avs: replace strcmp with sysfs_streq

[Brahmajit Das]

On 23.12.2025 19:24, Amadeusz Sławiński wrote:
> On Tue, 23 Dec 2025 17:07:04 +0000
> Mark Brown <broonie@kernel.org> wrote:
> 
...snip...
> 
> Missed this patch and it got applied...
> 
> Anyway above log seems bit weird, as this struct should be well defined:
> struct avs_tplg_path_template_id {
> 	u32 id;
> 	char tplg_name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN];
> };
> are you sure that SNDRV_CTL_ELEM_ID_NAME_MAXLEN didn't somehow end up
> being 0? As that would be a real problem.
> 
> sysfs_streq is similar to strcmp, but with different order of checks so
> it will just mask an issue, if there really is one. And reading its
> description I don't think it should be used in this case.
> 
> Can you instead try reverting it and hardcoding value in struct like:
> struct avs_tplg_path_template_id {
> 	u32 id;
> 	char tplg_name[44];
> };
> to see if the error is gone?

Does not seem to help, unfortunately :(

Current changes (after reverting my patch)

diff --git a/sound/soc/intel/avs/topology.h b/sound/soc/intel/avs/topology.h
index 1cf7455b6c01..ed839774bfe2 100644
--- a/sound/soc/intel/avs/topology.h
+++ b/sound/soc/intel/avs/topology.h
@@ -150,7 +150,7 @@ struct avs_tplg_binding {

 struct avs_tplg_path_template_id {
        u32 id;
-       char tplg_name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN];
+       char tplg_name[44];
 };

 struct avs_tplg_path_template {

Build output:


  CALL    scripts/checksyscalls.sh
  DESCEND objtool
  INSTALL libsubcmd_headers
  CC [M]  sound/soc/intel/avs/path.o
In function ‘avs_tplg_path_template_id_equal’,
    inlined from ‘avs_condpath_find_match’ at sound/soc/intel/avs/path.c:160:6,
    inlined from ‘avs_condpaths_walk’ at sound/soc/intel/avs/path.c:1274:13:
sound/soc/intel/avs/path.c:137:38: error: ‘strcmp’ reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
  137 |         return id->id == id2->id && !strcmp(id->tplg_name, id2->tplg_name);
      |                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ‘avs_condpaths_walk’: events 1-3
  137 |         return id->id == id2->id && !strcmp(id->tplg_name, id2->tplg_name);
      |                ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                  |   |
      |                                  |   (3) warning happens here
      |                                  (1) when the condition is evaluated to true
......
  155 |         if (id->id != path->template->owner->id ||
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                                 |
      |                                                 (2) when the condition is evaluated to false
  156 |             strcmp(id->tplg_name, path->template->owner->owner->name))
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from sound/soc/intel/avs/path.h:14,
                 from sound/soc/intel/avs/path.c:15:
sound/soc/intel/avs/topology.h: In function ‘avs_condpaths_walk’:
sound/soc/intel/avs/topology.h:152:13: note: at offset 4 into source object ‘id’ of size 4
  152 |         u32 id;
      |             ^~
sound/soc/intel/avs/topology.h:152:13: note: at offset 4 into source object ‘id’ of size 4
cc1: all warnings being treated as errors
make[6]: *** [scripts/Makefile.build:287: sound/soc/intel/avs/path.o] Error 1
make[5]: *** [scripts/Makefile.build:556: sound/soc/intel/avs] Error 2
make[4]: *** [scripts/Makefile.build:556: sound/soc/intel] Error 2
make[3]: *** [scripts/Makefile.build:556: sound/soc] Error 2
make[2]: *** [scripts/Makefile.build:556: sound] Error 2
make[1]: *** [/home/bdas/linux/Makefile:2060: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2
-- 
Regards,
listout

Re: [PATCH] ASoC: Intel: avs: replace strcmp with sysfs_streq

[Takashi Iwai]

On Tue, 23 Dec 2025 21:57:09 +0100,
Brahmajit Das wrote:
> 
> On 23.12.2025 19:24, Amadeusz Sławiński wrote:
> > On Tue, 23 Dec 2025 17:07:04 +0000
> > Mark Brown <broonie@kernel.org> wrote:
> > 
> ...snip...
> > 
> > Missed this patch and it got applied...
> > 
> > Anyway above log seems bit weird, as this struct should be well defined:
> > struct avs_tplg_path_template_id {
> > 	u32 id;
> > 	char tplg_name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN];
> > };
> > are you sure that SNDRV_CTL_ELEM_ID_NAME_MAXLEN didn't somehow end up
> > being 0? As that would be a real problem.
> > 
> > sysfs_streq is similar to strcmp, but with different order of checks so
> > it will just mask an issue, if there really is one. And reading its
> > description I don't think it should be used in this case.
> > 
> > Can you instead try reverting it and hardcoding value in struct like:
> > struct avs_tplg_path_template_id {
> > 	u32 id;
> > 	char tplg_name[44];
> > };
> > to see if the error is gone?
> 
> Does not seem to help, unfortunately :(
> 
> Current changes (after reverting my patch)
> 
> diff --git a/sound/soc/intel/avs/topology.h b/sound/soc/intel/avs/topology.h
> index 1cf7455b6c01..ed839774bfe2 100644
> --- a/sound/soc/intel/avs/topology.h
> +++ b/sound/soc/intel/avs/topology.h
> @@ -150,7 +150,7 @@ struct avs_tplg_binding {
> 
>  struct avs_tplg_path_template_id {
>         u32 id;
> -       char tplg_name[SNDRV_CTL_ELEM_ID_NAME_MAXLEN];
> +       char tplg_name[44];
>  };
> 
>  struct avs_tplg_path_template {
> 
> Build output:
> 
> 
>   CALL    scripts/checksyscalls.sh
>   DESCEND objtool
>   INSTALL libsubcmd_headers
>   CC [M]  sound/soc/intel/avs/path.o
> In function ‘avs_tplg_path_template_id_equal’,
>     inlined from ‘avs_condpath_find_match’ at sound/soc/intel/avs/path.c:160:6,
>     inlined from ‘avs_condpaths_walk’ at sound/soc/intel/avs/path.c:1274:13:
> sound/soc/intel/avs/path.c:137:38: error: ‘strcmp’ reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread]
>   137 |         return id->id == id2->id && !strcmp(id->tplg_name, id2->tplg_name);
>       |                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   ‘avs_condpaths_walk’: events 1-3
>   137 |         return id->id == id2->id && !strcmp(id->tplg_name, id2->tplg_name);
>       |                ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       |                                  |   |
>       |                                  |   (3) warning happens here
>       |                                  (1) when the condition is evaluated to true
> ......
>   155 |         if (id->id != path->template->owner->id ||
>       |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>       |                                                 |
>       |                                                 (2) when the condition is evaluated to false
>   156 |             strcmp(id->tplg_name, path->template->owner->owner->name))
>       |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from sound/soc/intel/avs/path.h:14,
>                  from sound/soc/intel/avs/path.c:15:
> sound/soc/intel/avs/topology.h: In function ‘avs_condpaths_walk’:
> sound/soc/intel/avs/topology.h:152:13: note: at offset 4 into source object ‘id’ of size 4
>   152 |         u32 id;
>       |             ^~
> sound/soc/intel/avs/topology.h:152:13: note: at offset 4 into source object ‘id’ of size 4
> cc1: all warnings being treated as errors
> make[6]: *** [scripts/Makefile.build:287: sound/soc/intel/avs/path.o] Error 1
> make[5]: *** [scripts/Makefile.build:556: sound/soc/intel/avs] Error 2
> make[4]: *** [scripts/Makefile.build:556: sound/soc/intel] Error 2
> make[3]: *** [scripts/Makefile.build:556: sound/soc] Error 2
> make[2]: *** [scripts/Makefile.build:556: sound] Error 2
> make[1]: *** [/home/bdas/linux/Makefile:2060: .] Error 2
> make: *** [Makefile:248: __sub-make] Error 2

I believe it's a false positive, too.
Or is it about potentially unterminated strings?


Takashi

Re: [PATCH] ASoC: Intel: avs: replace strcmp with sysfs_streq

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 242 bytes --]

On Wed, Dec 24, 2025 at 11:05:56AM +0100, Takashi Iwai wrote:

> I believe it's a false positive, too.
> Or is it about potentially unterminated strings?

Regardless of the warning being spurious or not the cleanup seems like a
sensible one.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH] ASoC: Intel: avs: replace strcmp with sysfs_streq

[Cezary Rojewski]

On 2025-12-24 12:35 PM, Mark Brown wrote:
> On Wed, Dec 24, 2025 at 11:05:56AM +0100, Takashi Iwai wrote:
> 
>> I believe it's a false positive, too.
>> Or is it about potentially unterminated strings?
> 
> Regardless of the warning being spurious or not the cleanup seems like a
> sensible one.

Right now I leaning towards Amadeusz' opinion - looks like we're masking 
an issue. id->tplg_name is being used in strcmp() context few times in 
this file yet compiler complains about one particular location.

gcc-16 is quite recent. It's good that we get the kernel building but 
after the Christmas break some digging may be in order : )


Brahmajit,

While I'm sure you did, just to be sure - did you try clean-rebuild with 
the 44-hardcode proposed by Amadeusz? We wouldn't want any old-artifacts 
to get in the way.


Kind regards,
Czarek

Re: [PATCH] ASoC: Intel: avs: replace strcmp with sysfs_streq

[Brahmajit Das]

On 29.12.2025 11:03, Cezary Rojewski wrote:
> On 2025-12-24 12:35 PM, Mark Brown wrote:
> > On Wed, Dec 24, 2025 at 11:05:56AM +0100, Takashi Iwai wrote:
> > 
> > > I believe it's a false positive, too.
> > > Or is it about potentially unterminated strings?
> > 
> > Regardless of the warning being spurious or not the cleanup seems like a
> > sensible one.
> 
> Right now I leaning towards Amadeusz' opinion - looks like we're masking an
> issue. id->tplg_name is being used in strcmp() context few times in this
> file yet compiler complains about one particular location.
> 
> gcc-16 is quite recent. It's good that we get the kernel building but after
> the Christmas break some digging may be in order : )
> 
> 
> Brahmajit,
> 
> While I'm sure you did, just to be sure - did you try clean-rebuild with the
> 44-hardcode proposed by Amadeusz? We wouldn't want any old-artifacts to get
> in the way.

Hi Cezary,

Yes, I did make clean and make allmodconfig after reverting my changes
and hardcoding 44 as Amadeusz suggested.

-- 
Regards,
listout

Re: [PATCH] ASoC: Intel: avs: replace strcmp with sysfs_streq

[Brahmajit Das]

On 29.12.2025 11:03, Cezary Rojewski wrote:
> On 2025-12-24 12:35 PM, Mark Brown wrote:
> > On Wed, Dec 24, 2025 at 11:05:56AM +0100, Takashi Iwai wrote:
> > 
> > > I believe it's a false positive, too.
> > > Or is it about potentially unterminated strings?
> > 
> > Regardless of the warning being spurious or not the cleanup seems like a
> > sensible one.
> 
...
> Brahmajit,
> 
> While I'm sure you did, just to be sure - did you try clean-rebuild with the
> 44-hardcode proposed by Amadeusz? We wouldn't want any old-artifacts to get
> in the way.
> 
> 
> Kind regards,
> Czarek

Czarek,

Not sure if it would help but I tracked or narrowed down the issue to
this section of the code in the avs_condpaths_walk function.


	if (avs_tplg_path_template_id_equal(&template->source,
										&template->sink) && dir)
		continue;

If I just comment that code segment out, then it builds successfully;
both with and without the hard coded name length.

I was also looking into GCC bugzilla and there seems to lot of reports
saying these kind of error could be bogus or false positive. I'm not
familiar with GCC internal or experienced in compilers to say/understand
whether this case in particular is a false positive or not.

BTW I can't seem to send the email to Amadeusz, hence removing them from
the CC-list
> msmtp: recipient address amade@asmblr.net not accepted by the server
-- 
Regards,
listout

Re: [PATCH] ASoC: Intel: avs: replace strcmp with sysfs_streq

[Cezary Rojewski]

On 2025-12-30 9:32 AM, Brahmajit Das wrote:
> On 29.12.2025 11:03, Cezary Rojewski wrote:

...

>> Brahmajit,
>>
>> While I'm sure you did, just to be sure - did you try clean-rebuild with the
>> 44-hardcode proposed by Amadeusz? We wouldn't want any old-artifacts to get
>> in the way.
>>
>>
>> Kind regards,
>> Czarek
> 
> Czarek,
> 
> Not sure if it would help but I tracked or narrowed down the issue to
> this section of the code in the avs_condpaths_walk function.
> 
> 
> 	if (avs_tplg_path_template_id_equal(&template->source,
> 										&template->sink) && dir)
> 		continue;
> 
> If I just comment that code segment out, then it builds successfully;
> both with and without the hard coded name length.

Outstanding! Thank you for this exercise.

> I was also looking into GCC bugzilla and there seems to lot of reports
> saying these kind of error could be bogus or false positive. I'm not
> familiar with GCC internal or experienced in compilers to say/understand
> whether this case in particular is a false positive or not.

Wouldn't be the first time, though having successful builds ain't wrong 
either. After all we have git log and incremental changes/reverts are 
not a problem.

> BTW I can't seem to send the email to Amadeusz, hence removing them from
> the CC-list
>> msmtp: recipient address amade@asmblr.net not accepted by the server

That's weird. The @linux.intel.com is gone but what you mentioned is the 
correct one.

Re: [PATCH] ASoC: Intel: avs: replace strcmp with sysfs_streq

[Amadeusz Sławiński]

On Tue, 30 Dec 2025 10:36:27 +0100
Cezary Rojewski <cezary.rojewski@intel.com> wrote:

> On 2025-12-30 9:32 AM, Brahmajit Das wrote:
> > 
> > Not sure if it would help but I tracked or narrowed down the issue to
> > this section of the code in the avs_condpaths_walk function.
> > 
> > 
> > 	if (avs_tplg_path_template_id_equal(&template->source,
> > 										&template->sink) && dir)
> > 		continue;
> > 
> > If I just comment that code segment out, then it builds successfully;
> > both with and without the hard coded name length.  
> 
> Outstanding! Thank you for this exercise.

Yes, I also managed to reproduce it on my machine.

You can also just reverse the order in
avs_tplg_path_template_id_equal() to:
return !strcmp(id->tplg_name, id2->tplg_name) && id->id == id2->id;
which for some reason makes the error disappear.

> > I was also looking into GCC bugzilla and there seems to lot of reports
> > saying these kind of error could be bogus or false positive. I'm not
> > familiar with GCC internal or experienced in compilers to say/understand
> > whether this case in particular is a false positive or not.  
> 
> Wouldn't be the first time, though having successful builds ain't wrong 
> either. After all we have git log and incremental changes/reverts are 
> not a problem.
> 

I've bisected it down on GCC side to:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commitdiff;h=fc62834533f357125b9c1934f80c2ba249adbf9e
in particular it seems to be caused by code added in gcc/tree-ssa-pre.cc
I'm not that familiar with how GCC works, but to me it seems like maybe
it loses size information during this conversion.

I would make normal bug report, but apparently I can't just make GCC
bugzilla account, so adding Richard to CC, while I go through request
process for an account.

@Richard
Hi, we seem to have hit a slight problem while building kernel with pre
release GCC caused by one of your patches, full thread is available
here:
https://lore.kernel.org/linux-sound/20251221185531.6453-1-listout@listout.xyz/T/#u
and my reasoning above.

> > BTW I can't seem to send the email to Amadeusz, hence removing them from
> > the CC-list  
> >> msmtp: recipient address amade@asmblr.net not accepted by the server  
> 
> That's weird. The @linux.intel.com is gone but what you mentioned is the 
> correct one.

Yup, that's weird, but nothing lost, I'm subscribed to mailing list ;)

Re: [PATCH] ASoC: Intel: avs: replace strcmp with sysfs_streq

[Richard Biener]

> Am 30.12.2025 um 13:25 schrieb Amadeusz Sławiński <amade@asmblr.net>:
> 
> On Tue, 30 Dec 2025 10:36:27 +0100
> Cezary Rojewski <cezary.rojewski@intel.com> wrote:
> 
>>> On 2025-12-30 9:32 AM, Brahmajit Das wrote:
>>> 
>>> Not sure if it would help but I tracked or narrowed down the issue to
>>> this section of the code in the avs_condpaths_walk function.
>>> 
>>> 
>>>    if (avs_tplg_path_template_id_equal(&template->source,
>>>                                        &template->sink) && dir)
>>>        continue;
>>> 
>>> If I just comment that code segment out, then it builds successfully;
>>> both with and without the hard coded name length.  
>> 
>> Outstanding! Thank you for this exercise.
> 
> Yes, I also managed to reproduce it on my machine.
> 
> You can also just reverse the order in
> avs_tplg_path_template_id_equal() to:
> return !strcmp(id->tplg_name, id2->tplg_name) && id->id == id2->id;
> which for some reason makes the error disappear.
> 
>>> I was also looking into GCC bugzilla and there seems to lot of reports
>>> saying these kind of error could be bogus or false positive. I'm not
>>> familiar with GCC internal or experienced in compilers to say/understand
>>> whether this case in particular is a false positive or not.  
>> 
>> Wouldn't be the first time, though having successful builds ain't wrong
>> either. After all we have git log and incremental changes/reverts are
>> not a problem.
>> 
> 
> I've bisected it down on GCC side to:
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=commitdiff;h=fc62834533f357125b9c1934f80c2ba249adbf9e
> in particular it seems to be caused by code added in gcc/tree-ssa-pre.cc
> I'm not that familiar with how GCC works, but to me it seems like maybe
> it loses size information during this conversion.
> 
> I would make normal bug report, but apparently I can't just make GCC
> bugzilla account, so adding Richard to CC, while I go through request
> process for an account.
> 
> @Richard
> Hi, we seem to have hit a slight problem while building kernel with pre
> release GCC caused by one of your patches, full thread is available
> here:
> https://lore.kernel.org/linux-sound/20251221185531.6453-1-listout@listout.xyz/T/#u
> and my reasoning above.

It would be great if you can share preprocessed source to reproduce the issue, ideally attached to a new bugreport on the GCC bugzilla.

I’ll note the diagnostic in question is highly dependent on prior optimization and known to be prone to false positives.  I’ll investigate after holidays.

Richard 

>>> BTW I can't seem to send the email to Amadeusz, hence removing them from
>>> the CC-list  
>>>> msmtp: recipient address amade@asmblr.net not accepted by the server  
>> 
>> That's weird. The @linux.intel.com is gone but what you mentioned is the
>> correct one.
> 
> Yup, that's weird, but nothing lost, I'm subscribed to mailing list ;)