The Linux kernel's minimum GCC version requirement has been bumped
from 4.3 to 8.3, but this tool still fails to compile with GCC 8.3.

Older compilers would fail if did not include parameter names in
function declarations that contained parameter types; newer compilers
are more lenient about this.

Fix many errors like this:
  In file included from vma.c:10:
  vma_internal.h: In function ‘arch_validate_flags’:
  vma_internal.h:1218:40: error: parameter name omitted
   static inline bool arch_validate_flags(unsigned long)
                                        ^~~~~~~~~~~~~
  vma.c: In function ‘dummy_close’:
  vma.c:281:25: error: parameter name omitted
   static void dummy_close(struct vm_area_struct *)
                         ^~~~~~~~~~~~~~~~~~~~~~~

Reported-by: Jun Zhan <zhanjun@uniontech.com>
Signed-off-by: WangYuli <wangyuli@uniontech.com>
---
 tools/testing/vma/vma.c          |   2 +-
 tools/testing/vma/vma_internal.h | 110 +++++++++++++++----------------
 2 files changed, 56 insertions(+), 56 deletions(-)

diff --git a/tools/testing/vma/vma.c b/tools/testing/vma/vma.c
index 2be7597a2ac2..390b6a711f97 100644
--- a/tools/testing/vma/vma.c
+++ b/tools/testing/vma/vma.c
@@ -278,7 +278,7 @@ static bool vma_write_started(struct vm_area_struct *vma)
 }
 
 /* Helper function providing a dummy vm_ops->close() method.*/
-static void dummy_close(struct vm_area_struct *)
+static void dummy_close(struct vm_area_struct *vma)
 {
 }
 
diff --git a/tools/testing/vma/vma_internal.h b/tools/testing/vma/vma_internal.h
index 816e7e057585..4935460102e5 100644
--- a/tools/testing/vma/vma_internal.h
+++ b/tools/testing/vma/vma_internal.h
@@ -288,8 +288,8 @@ struct vm_area_desc {
 };
 
 struct file_operations {
-	int (*mmap)(struct file *, struct vm_area_struct *);
-	int (*mmap_prepare)(struct vm_area_desc *);
+	int (*mmap)(struct file *file, struct vm_area_struct *vma);
+	int (*mmap_prepare)(struct vm_area_desc *desc);
 };
 
 struct file {
@@ -840,11 +840,11 @@ static inline unsigned long vma_pages(struct vm_area_struct *vma)
 	return (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
 }
 
-static inline void fput(struct file *)
+static inline void fput(struct file *file)
 {
 }
 
-static inline void mpol_put(struct mempolicy *)
+static inline void mpol_put(struct mempolicy *policy)
 {
 }
 
@@ -852,15 +852,15 @@ static inline void lru_add_drain(void)
 {
 }
 
-static inline void tlb_gather_mmu(struct mmu_gather *, struct mm_struct *)
+static inline void tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm)
 {
 }
 
-static inline void update_hiwater_rss(struct mm_struct *)
+static inline void update_hiwater_rss(struct mm_struct *mm)
 {
 }
 
-static inline void update_hiwater_vm(struct mm_struct *)
+static inline void update_hiwater_vm(struct mm_struct *mm)
 {
 }
 
@@ -890,15 +890,15 @@ static inline void free_pgtables(struct mmu_gather *tlb, struct ma_state *mas,
 	(void)mm_wr_locked;
 }
 
-static inline void mapping_unmap_writable(struct address_space *)
+static inline void mapping_unmap_writable(struct address_space *mapping)
 {
 }
 
-static inline void flush_dcache_mmap_lock(struct address_space *)
+static inline void flush_dcache_mmap_lock(struct address_space *mapping)
 {
 }
 
-static inline void tlb_finish_mmu(struct mmu_gather *)
+static inline void tlb_finish_mmu(struct mmu_gather *tlb)
 {
 }
 
@@ -907,7 +907,7 @@ static inline struct file *get_file(struct file *f)
 	return f;
 }
 
-static inline int vma_dup_policy(struct vm_area_struct *, struct vm_area_struct *)
+static inline int vma_dup_policy(struct vm_area_struct *dst, struct vm_area_struct *src)
 {
 	return 0;
 }
@@ -940,7 +940,7 @@ static inline void vma_adjust_trans_huge(struct vm_area_struct *vma,
 	(void)next;
 }
 
-static inline void hugetlb_split(struct vm_area_struct *, unsigned long) {}
+static inline void hugetlb_split(struct vm_area_struct *vma, unsigned long addr) {}
 
 static inline void vma_iter_free(struct vma_iterator *vmi)
 {
@@ -957,31 +957,31 @@ static inline void vm_acct_memory(long pages)
 {
 }
 
-static inline void vma_interval_tree_insert(struct vm_area_struct *,
-					    struct rb_root_cached *)
+static inline void vma_interval_tree_insert(struct vm_area_struct *vma,
+					    struct rb_root_cached *root)
 {
 }
 
-static inline void vma_interval_tree_remove(struct vm_area_struct *,
-					    struct rb_root_cached *)
+static inline void vma_interval_tree_remove(struct vm_area_struct *vma,
+					    struct rb_root_cached *root)
 {
 }
 
-static inline void flush_dcache_mmap_unlock(struct address_space *)
+static inline void flush_dcache_mmap_unlock(struct address_space *mapping)
 {
 }
 
-static inline void anon_vma_interval_tree_insert(struct anon_vma_chain*,
-						 struct rb_root_cached *)
+static inline void anon_vma_interval_tree_insert(struct anon_vma_chain *avc,
+						 struct rb_root_cached *root)
 {
 }
 
-static inline void anon_vma_interval_tree_remove(struct anon_vma_chain*,
-						 struct rb_root_cached *)
+static inline void anon_vma_interval_tree_remove(struct anon_vma_chain *avc,
+						 struct rb_root_cached *root)
 {
 }
 
-static inline void uprobe_mmap(struct vm_area_struct *)
+static inline void uprobe_mmap(struct vm_area_struct *vma)
 {
 }
 
@@ -993,15 +993,15 @@ static inline void uprobe_munmap(struct vm_area_struct *vma,
 	(void)end;
 }
 
-static inline void i_mmap_lock_write(struct address_space *)
+static inline void i_mmap_lock_write(struct address_space *mapping)
 {
 }
 
-static inline void anon_vma_lock_write(struct anon_vma *)
+static inline void anon_vma_lock_write(struct anon_vma *anon_vma)
 {
 }
 
-static inline void vma_assert_write_locked(struct vm_area_struct *)
+static inline void vma_assert_write_locked(struct vm_area_struct *vma)
 {
 }
 
@@ -1011,16 +1011,16 @@ static inline void unlink_anon_vmas(struct vm_area_struct *vma)
 	vma->anon_vma->was_unlinked = true;
 }
 
-static inline void anon_vma_unlock_write(struct anon_vma *)
+static inline void anon_vma_unlock_write(struct anon_vma *anon_vma)
 {
 }
 
-static inline void i_mmap_unlock_write(struct address_space *)
+static inline void i_mmap_unlock_write(struct address_space *mapping)
 {
 }
 
-static inline void anon_vma_merge(struct vm_area_struct *,
-				  struct vm_area_struct *)
+static inline void anon_vma_merge(struct vm_area_struct *vma,
+				  struct vm_area_struct *prev)
 {
 }
 
@@ -1037,19 +1037,19 @@ static inline int userfaultfd_unmap_prep(struct vm_area_struct *vma,
 	return 0;
 }
 
-static inline void mmap_write_downgrade(struct mm_struct *)
+static inline void mmap_write_downgrade(struct mm_struct *mm)
 {
 }
 
-static inline void mmap_read_unlock(struct mm_struct *)
+static inline void mmap_read_unlock(struct mm_struct *mm)
 {
 }
 
-static inline void mmap_write_unlock(struct mm_struct *)
+static inline void mmap_write_unlock(struct mm_struct *mm)
 {
 }
 
-static inline int mmap_write_lock_killable(struct mm_struct *)
+static inline int mmap_write_lock_killable(struct mm_struct *mm)
 {
 	return 0;
 }
@@ -1074,11 +1074,11 @@ static inline void arch_unmap(struct mm_struct *mm,
 	(void)end;
 }
 
-static inline void mmap_assert_locked(struct mm_struct *)
+static inline void mmap_assert_locked(struct mm_struct *mm)
 {
 }
 
-static inline bool mpol_equal(struct mempolicy *, struct mempolicy *)
+static inline bool mpol_equal(struct mempolicy *a, struct mempolicy *b)
 {
 	return true;
 }
@@ -1090,59 +1090,59 @@ static inline void khugepaged_enter_vma(struct vm_area_struct *vma,
 	(void)vm_flags;
 }
 
-static inline bool mapping_can_writeback(struct address_space *)
+static inline bool mapping_can_writeback(struct address_space *mapping)
 {
 	return true;
 }
 
-static inline bool is_vm_hugetlb_page(struct vm_area_struct *)
+static inline bool is_vm_hugetlb_page(struct vm_area_struct *vma)
 {
 	return false;
 }
 
-static inline bool vma_soft_dirty_enabled(struct vm_area_struct *)
+static inline bool vma_soft_dirty_enabled(struct vm_area_struct *vma)
 {
 	return false;
 }
 
-static inline bool userfaultfd_wp(struct vm_area_struct *)
+static inline bool userfaultfd_wp(struct vm_area_struct *vma)
 {
 	return false;
 }
 
-static inline void mmap_assert_write_locked(struct mm_struct *)
+static inline void mmap_assert_write_locked(struct mm_struct *mm)
 {
 }
 
-static inline void mutex_lock(struct mutex *)
+static inline void mutex_lock(struct mutex *lock)
 {
 }
 
-static inline void mutex_unlock(struct mutex *)
+static inline void mutex_unlock(struct mutex *lock)
 {
 }
 
-static inline bool mutex_is_locked(struct mutex *)
+static inline bool mutex_is_locked(struct mutex *lock)
 {
 	return true;
 }
 
-static inline bool signal_pending(void *)
+static inline bool signal_pending(void *task)
 {
 	return false;
 }
 
-static inline bool is_file_hugepages(struct file *)
+static inline bool is_file_hugepages(struct file *file)
 {
 	return false;
 }
 
-static inline int security_vm_enough_memory_mm(struct mm_struct *, long)
+static inline int security_vm_enough_memory_mm(struct mm_struct *mm, long pages)
 {
 	return 0;
 }
 
-static inline bool may_expand_vm(struct mm_struct *, vm_flags_t, unsigned long)
+static inline bool may_expand_vm(struct mm_struct *mm, vm_flags_t flags, unsigned long npages)
 {
 	return true;
 }
@@ -1167,7 +1167,7 @@ static inline void vm_flags_clear(struct vm_area_struct *vma,
 	vma->__vm_flags &= ~flags;
 }
 
-static inline int shmem_zero_setup(struct vm_area_struct *)
+static inline int shmem_zero_setup(struct vm_area_struct *vma)
 {
 	return 0;
 }
@@ -1177,20 +1177,20 @@ static inline void vma_set_anonymous(struct vm_area_struct *vma)
 	vma->vm_ops = NULL;
 }
 
-static inline void ksm_add_vma(struct vm_area_struct *)
+static inline void ksm_add_vma(struct vm_area_struct *vma)
 {
 }
 
-static inline void perf_event_mmap(struct vm_area_struct *)
+static inline void perf_event_mmap(struct vm_area_struct *vma)
 {
 }
 
-static inline bool vma_is_dax(struct vm_area_struct *)
+static inline bool vma_is_dax(struct vm_area_struct *vma)
 {
 	return false;
 }
 
-static inline struct vm_area_struct *get_gate_vma(struct mm_struct *)
+static inline struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
 {
 	return NULL;
 }
@@ -1215,16 +1215,16 @@ static inline void vma_set_page_prot(struct vm_area_struct *vma)
 	WRITE_ONCE(vma->vm_page_prot, vm_page_prot);
 }
 
-static inline bool arch_validate_flags(unsigned long)
+static inline bool arch_validate_flags(unsigned long flags)
 {
 	return true;
 }
 
-static inline void vma_close(struct vm_area_struct *)
+static inline void vma_close(struct vm_area_struct *vma)
 {
 }
 
-static inline int mmap_file(struct file *, struct vm_area_struct *)
+static inline int mmap_file(struct file *file, struct vm_area_struct *vma)
 {
 	return 0;
 }
-- 
2.50.0

On Tue, Jul 29, 2025 at 04:47:00PM +0800, WangYuli wrote:
> The Linux kernel's minimum GCC version requirement has been bumped
> from 4.3 to 8.3, but this tool still fails to compile with GCC 8.3.

Why people keep reporting this for my VMA test series but _not_ the kernel
as a whole I don't know.

$ grep "\*);" include/linux/mm.h | wc -l
9

^--- If you use such a compiler, the kernel won't build.

So the bug is whoever is saying a version of gcc that does the below (I'll
take your word for it that this is in a normal configuraiton) is OK for the
kernel.

It's clearly not.

Oh just to underline things:

$ find include/linux -name '*.h' | xargs grep "\*);" | wc -l
1899

So y'know.

>
> Older compilers would fail if did not include parameter names in
> function declarations that contained parameter types; newer compilers
> are more lenient about this.

You're using a compiler that won't build linux. Stop it?

>
> Fix many errors like this:
>   In file included from vma.c:10:
>   vma_internal.h: In function ‘arch_validate_flags’:
>   vma_internal.h:1218:40: error: parameter name omitted
>    static inline bool arch_validate_flags(unsigned long)
>                                         ^~~~~~~~~~~~~
>   vma.c: In function ‘dummy_close’:
>   vma.c:281:25: error: parameter name omitted
>    static void dummy_close(struct vm_area_struct *)
>                          ^~~~~~~~~~~~~~~~~~~~~~~
>
> Reported-by: Jun Zhan <zhanjun@uniontech.com>
> Signed-off-by: WangYuli <wangyuli@uniontech.com>

NAK.

Hi Lorenzo Stoakes,

On 2025/7/29 17:06, Lorenzo Stoakes wrote:
> On Tue, Jul 29, 2025 at 04:47:00PM +0800, WangYuli wrote:
>> The Linux kernel's minimum GCC version requirement has been bumped
>> from 4.3 to 8.3, but this tool still fails to compile with GCC 8.3.
> Why people keep reporting this for my VMA test series but _not_ the kernel
> as a whole I don't know.
>
> $ grep "\*);" include/linux/mm.h | wc -l
> 9
>
> ^--- If you use such a compiler, the kernel won't build.
>
> So the bug is whoever is saying a version of gcc that does the below (I'll
> take your word for it that this is in a normal configuraiton) is OK for the
> kernel.
>
> It's clearly not.
>
> Oh just to underline things:
>
> $ find include/linux -name '*.h' | xargs grep "\*);" | wc -l
> 1899
>
> So y'know.
>
>> Older compilers would fail if did not include parameter names in
>> function declarations that contained parameter types; newer compilers
>> are more lenient about this.
> You're using a compiler that won't build linux. Stop it?
>
>> Fix many errors like this:
>>    In file included from vma.c:10:
>>    vma_internal.h: In function ‘arch_validate_flags’:
>>    vma_internal.h:1218:40: error: parameter name omitted
>>     static inline bool arch_validate_flags(unsigned long)
>>                                          ^~~~~~~~~~~~~
>>    vma.c: In function ‘dummy_close’:
>>    vma.c:281:25: error: parameter name omitted
>>     static void dummy_close(struct vm_area_struct *)
>>                           ^~~~~~~~~~~~~~~~~~~~~~~
>>
>> Reported-by: Jun Zhan <zhanjun@uniontech.com>
>> Signed-off-by: WangYuli <wangyuli@uniontech.com>
> NAK.
>
Thanks for the heads-up! I noticed that coding style in the kernel code 
as well.

However, GCC 8.3 (which does meet the kernel's compiler version 
requirements) can compile the kernel code normally, but it can't compile 
vma's test correctly.

Could the issue be related to differences in compilation parameters? 
I'll need to spend some time looking into this more closely...

By the way, this coding style has been a GNU C extension until the ISO 
C23 standard. So, until the kernel's C language standard is upgraded to 
C23 (which seems unlikely to happen anytime soon, perhaps years down the 
line), it actually makes sense to modify this style for a practical 
purpose...

[ Cc the kbuild list. ]

Thanks,

-- 
WangYuli

On Thu, Jul 31, 2025 at 10:55:32AM +0800, WangYuli wrote:
> >
> Thanks for the heads-up! I noticed that coding style in the kernel code as
> well.
>
> However, GCC 8.3 (which does meet the kernel's compiler version
> requirements) can compile the kernel code normally, but it can't compile
> vma's test correctly.
>
> Could the issue be related to differences in compilation parameters? I'll
> need to spend some time looking into this more closely...

OK thanks please do check, am happy to have a patch to add a flag if
appropriate! :)

>
> By the way, this coding style has been a GNU C extension until the ISO C23
> standard. So, until the kernel's C language standard is upgraded to C23
> (which seems unlikely to happen anytime soon, perhaps years down the line),
> it actually makes sense to modify this style for a practical purpose...

Kernel always uses the GNU C standard by convention, so we should be good,
but indeed I think this is the case!

The irony here is that I actually intend to change stubs in this header to
remove parameter names (previously had review on this :).

>
> [ Cc the kbuild list. ]

Thanks

>
> Thanks,
>
> --
> WangYuli

Cheers, Lorenzo

On 7/31/25 12:24, Lorenzo Stoakes wrote:
> On Thu, Jul 31, 2025 at 10:55:32AM +0800, WangYuli wrote:
>> >
>> Thanks for the heads-up! I noticed that coding style in the kernel code as
>> well.
>>
>> However, GCC 8.3 (which does meet the kernel's compiler version
>> requirements) can compile the kernel code normally, but it can't compile
>> vma's test correctly.
>>
>> Could the issue be related to differences in compilation parameters? I'll
>> need to spend some time looking into this more closely...
> 
> OK thanks please do check, am happy to have a patch to add a flag if
> appropriate! :)
> 
>>
>> By the way, this coding style has been a GNU C extension until the ISO C23
>> standard. So, until the kernel's C language standard is upgraded to C23
>> (which seems unlikely to happen anytime soon, perhaps years down the line),
>> it actually makes sense to modify this style for a practical purpose...
> 
> Kernel always uses the GNU C standard by convention, so we should be good,
> but indeed I think this is the case!

I think it's not "by convention" but quite explicitly by:

Makefile:KBUILD_CFLAGS += -std=gnu11

I think this is not automatically used by tools/ build?

If you git grep gnu11, you'll find various Makefile's under tools/ adding
that to CFLAGS. Maybe we can simply do that also with
tools/testing/shared/shared.mk
that's included for the vma tests.

I don't have this gcc version so can't try myself if it helps.

> The irony here is that I actually intend to change stubs in this header to
> remove parameter names (previously had review on this :).
> 
>>
>> [ Cc the kbuild list. ]
> 
> Thanks
> 
>>
>> Thanks,
>>
>> --
>> WangYuli
> 
> Cheers, Lorenzo

On Thu, Jul 31, 2025 at 08:13:55PM +0200, Vlastimil Babka wrote:
> >> By the way, this coding style has been a GNU C extension until the ISO C23
> >> standard. So, until the kernel's C language standard is upgraded to C23
> >> (which seems unlikely to happen anytime soon, perhaps years down the line),
> >> it actually makes sense to modify this style for a practical purpose...
> >
> > Kernel always uses the GNU C standard by convention, so we should be good,
> > but indeed I think this is the case!
>
> I think it's not "by convention" but quite explicitly by:
>
> Makefile:KBUILD_CFLAGS += -std=gnu11

I meant the kernel convention is to set a flag like this, obviously...!

>
> I think this is not automatically used by tools/ build?

Right.

>
> If you git grep gnu11, you'll find various Makefile's under tools/ adding
> that to CFLAGS. Maybe we can simply do that also with
> tools/testing/shared/shared.mk
> that's included for the vma tests.
>
> I don't have this gcc version so can't try myself if it helps.

WangYuli - could you check? If it's as simple as this, feel free to send a patch
making this change.

Thanks, Lorenzo

Hi all,

On 2025/8/1 13:14, Lorenzo Stoakes wrote:
> WangYuli - could you check? If it's as simple as this, feel free to send a patch
> making this change.
>
> Thanks, Lorenzo
>
It's not that simple, of course... That didn't work.

I'll take another look.

Thanks,

-- 
WangYuli

On 8/1/25 07:57, WangYuli wrote:
> Hi all,
> 
> On 2025/8/1 13:14, Lorenzo Stoakes wrote:
>> WangYuli - could you check? If it's as simple as this, feel free to send a patch
>> making this change.
>>
>> Thanks, Lorenzo
>>
> It's not that simple, of course... That didn't work.

Yeah seems I can reproduce it with gcc-7.5 and it doesn't work.

I think there is a difference with the other instances of omitted names
found by grep as Lorenzo suggested earlier - those seem to all be
declarations. But here in vma_internal.h they are (empty) static inline
definitions.

Seems like newer gcc versions got more lenient. Haven't found why, but seems
they want it to stay like this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113825

But I don't know if there's a way to make older gcc's lenient too.

> I'll take another look.
> 
> Thanks,
>

On Fri, Aug 01, 2025 at 10:04:11AM +0200, Vlastimil Babka wrote:
> On 8/1/25 07:57, WangYuli wrote:
> > Hi all,
> >
> > On 2025/8/1 13:14, Lorenzo Stoakes wrote:
> >> WangYuli - could you check? If it's as simple as this, feel free to send a patch
> >> making this change.
> >>
> >> Thanks, Lorenzo
> >>
> > It's not that simple, of course... That didn't work.
>
> Yeah seems I can reproduce it with gcc-7.5 and it doesn't work.

I think we should still add this though to make it consistent with the rest
of the kernel.

>
> I think there is a difference with the other instances of omitted names
> found by grep as Lorenzo suggested earlier - those seem to all be
> declarations. But here in vma_internal.h they are (empty) static inline
> definitions.

Yep this seems to be the difference.

>
> Seems like newer gcc versions got more lenient. Haven't found why, but seems
> they want it to stay like this:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113825
>
> But I don't know if there's a way to make older gcc's lenient too.
>
> > I'll take another look.
> >
> > Thanks,
> >
>

WangYuli - apologies - this is my fault entirely, I misunderstood things
here.

I was wrong to dismiss this out of hand, I guess not many headers are doing
stubs like this, and I mistook this as being a general thing.

Could you please do a v2 where you add back in parameter names (and add
this compiler flag - I think we still should), but could you do me a favour
and also fixup some horrid stuff here?

I have functions like:

static inline void vma_adjust_trans_huge(struct vm_area_struct *vma,
					 unsigned long start,
					 unsigned long end,
					 struct vm_area_struct *next)
{
	(void)vma;
	(void)start;
	(void)end;
	(void)next;
}

Where I am trying to avoid 'unused param' warnings which... won't actually
arise.

So could you eliminate all these horrid (void) things as well ass adding
parameter names?

That'd be really helpful, thanks!

Cheers, Lorenzo

On 8/1/25 10:50, Lorenzo Stoakes wrote:
> On Fri, Aug 01, 2025 at 10:04:11AM +0200, Vlastimil Babka wrote:
>>
>> Seems like newer gcc versions got more lenient. Haven't found why, but seems
>> they want it to stay like this:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113825
>>
>> But I don't know if there's a way to make older gcc's lenient too.
>>
>> > I'll take another look.
>> >
>> > Thanks,
>> >
>>
> 
> WangYuli - apologies - this is my fault entirely, I misunderstood things
> here.
> 
> I was wrong to dismiss this out of hand, I guess not many headers are doing
> stubs like this, and I mistook this as being a general thing.
> 
> Could you please do a v2 where you add back in parameter names (and add
> this compiler flag - I think we still should),

It would be safer to add the compiler flag indeed, as we are including files
from mm/ in vma.c here, so if some change in mm/ files makes them rely on
syntax permitted only gnu11, we'd break the compilation of the test.

Also please update the commit log to talk about function definitions and not
function declarations, as that turned out to be the important detail. Thanks!

Hi Lorenzo,

Should I split this into two commits?

As Vlastimil Babka suggested, perhaps it would be better to add both the 
|-std=gnu11| and |-Wno-unused-parameter| flags to 
|tools/testing/shared/shared.mk|.

Thanks,

-- 
WangYuli

On Fri, Aug 01, 2025 at 05:26:50PM +0800, WangYuli wrote:
> Hi Lorenzo,
>
> Should I split this into two commits?
>
> As Vlastimil Babka suggested, perhaps it would be better to add both the
> |-std=gnu11| and |-Wno-unused-parameter| flags to
> |tools/testing/shared/shared.mk|.

Sure, perhaps 2 patches is best, 1 for changes to shared.mk and 1 for the
fixups to vma_internal.h.

Also note Vlasta's reply here, he suggested some other stuff.

Thanks very much for doing this, you're saving me some work by fixing up
the silly (void) stuff and I appreciate you fixing this for older gcc! :>)

I will make sure to review this once submitted.

Cheers, Lorenzo

On 8/1/25 11:33, Lorenzo Stoakes wrote:
> On Fri, Aug 01, 2025 at 05:26:50PM +0800, WangYuli wrote:
>> Hi Lorenzo,
>>
>> Should I split this into two commits?
>>
>> As Vlastimil Babka suggested, perhaps it would be better to add both the
>> |-std=gnu11| and |-Wno-unused-parameter| flags to
>> |tools/testing/shared/shared.mk|.

I did suggest -std=gnu11, but -Wno-unused-parameter shouldn't be necessary
as there's nothing enabling the warning that we need to override.

> Sure, perhaps 2 patches is best, 1 for changes to shared.mk and 1 for the
> fixups to vma_internal.h.

You could even do 3 patches - separate your original addition of parameters
from the removal of "(void)foo;". Somebody might care enough to backport the
compilation fix alone to older versions.
> Also note Vlasta's reply here, he suggested some other stuff.
> 
> Thanks very much for doing this, you're saving me some work by fixing up
> the silly (void) stuff and I appreciate you fixing this for older gcc! :>)
> 
> I will make sure to review this once submitted.
> 
> Cheers, Lorenzo