<snip>
> > >
> > >>
> > >> Building with SVE extension enabled stopped with error:
> > >>
> > >> error: ACLE function ‘svwhilelt_b64_s32’ requires ISA extension ‘sve’
> > >> 18 | #define PG64_256BIT svwhilelt_b64(0, 4)
> > >>
> > >> This is caused by unintentional cflags reset.
> > >> Fixed the issue by appending required flag to cflags instead of
> > >> overriding it.
> > >>
> > >> Fixes: 952ebacce4f2 ("net/hns3: support SVE Rx")
> > >> Cc: xavier.hu...@huawei.com
> > >> Cc: sta...@dpdk.org
> > >>
> > >> Signed-off-by: Ruifeng Wang <ruifeng.w...@arm.com>
> > >> ---
> > >> drivers/net/hns3/meson.build | 2 +-
> > >> 1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/net/hns3/meson.build
> > >> b/drivers/net/hns3/meson.build index 45cee34d9..798086357 100644
> > >> --- a/drivers/net/hns3/meson.build
> > >> +++ b/drivers/net/hns3/meson.build
> > >> @@ -32,7 +32,7 @@ deps += ['hash']
> > >> if arch_subdir == 'arm' and dpdk_conf.get('RTE_ARCH_64')
> > >> sources += files('hns3_rxtx_vec.c')
> > >> if cc.get_define('__ARM_FEATURE_SVE', args: machine_args) != ''
> > >> -cflags = ['-DCC_SVE_SUPPORT']
> > >> +cflags += ['-DCC_SVE_SUPPORT']
> > > This comment is unrelated to this patch. We need to be consistent
> > > with the
> > macro definitions. Is '__ARM_FEATURE_SVE' not enough? If we need to
> > define an additional flag, I would name it something like
> > 'RTE_ARM_FEATURE_SVE'.
> > >
> > I think the __ARM_FEATURE_SVE is ok. if use the gcc version included
> > SVE flag, it will be identified as __ARM_FEATURE_SVE. it is defined in
> > the ARM SVE document.
>
> Yes, we can rely on flags defined by compiler and no extra flag is needed.
> I can update in next version to remove this section from meson file and
> replace
> CC_SVE_SUPPORT in code.
Sounds good to me.
> > >> sources += files('hns3_rxtx_vec_sve.c')
> > >> endif
> > >> endif
> > >> --
> > >> 2.25.1
> > >
