From: "Paul E. McKenney" <paulmck@kernel.org> To: Stephen Rothwell <sfr@rothwell.id.au> Cc: lucas.dimarchi@intel.com, Stephen Rothwell <sfr@canb.auug.org.au>, Lucas De Marchi <lucas.demarchi@intel.com>, linux-kernel@vger.kernel.org, intel-xe@lists.freedesktop.org Subject: Re: [BUG] allmodconfig build error in next-20240108 Date: Tue, 9 Jan 2024 14:45:56 -0800 [thread overview] Message-ID: <d61dfe52-9567-4f62-98f5-5c1e00cb4708@paulmck-laptop> (raw) In-Reply-To: <20240110081155.48bb0cbd@oak> On Wed, Jan 10, 2024 at 08:11:55AM +1100, Stephen Rothwell wrote: > Hi Lucas, > > On Tue, 9 Jan 2024 10:58:40 -0600 Lucas De Marchi <lucas.demarchi@intel.com> wrote: > > > > On Mon, Jan 08, 2024 at 03:15:23PM -0800, Paul E. McKenney wrote: > > >On Tue, Jan 09, 2024 at 09:57:57AM +1100, Stephen Rothwell wrote: > > >> Hi Paul, > > >> > > >> On Mon, 8 Jan 2024 13:33:36 -0800 "Paul E. McKenney" <paulmck@kernel.org> wrote: > > >> > > > >> > Recent -next trees get the following build error for allmodconfig builds: > > >> > > > >> > ------------------------------------------------------------------------ > > >> > > > >> > drivers/gpu/drm/xe/xe_gt_pagefault.c: In function ‘xe_guc_pagefault_handler’: > > >> > ./include/linux/fortify-string.h:57:33: error: writing 16 bytes into a region of size 0 [-Werror=stringop-overflow=] > > >> > 57 | #define __underlying_memcpy __builtin_memcpy > > >> > | ^ > > >> > ./include/linux/fortify-string.h:644:9: note: in expansion of macro ‘__underlying_memcpy’ > > >> > 644 | __underlying_##op(p, q, __fortify_size); \ > > >> > | ^~~~~~~~~~~~~ > > >> > ./include/linux/fortify-string.h:689:26: note: in expansion of macro ‘__fortify_memcpy_chk’ > > >> > 689 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ > > >> > | ^~~~~~~~~~~~~~~~~~~~ > > >> > drivers/gpu/drm/xe/xe_gt_pagefault.c:340:17: note: in expansion of macro ‘memcpy’ > > >> > 340 | memcpy(pf_queue->data + pf_queue->tail, msg, len * sizeof(u32)); > > >> > | ^~~~~~ > > >> > In file included from drivers/gpu/drm/xe/xe_device_types.h:17, > > >> > from drivers/gpu/drm/xe/xe_vm_types.h:16, > > >> > from drivers/gpu/drm/xe/xe_bo.h:13, > > >> > from drivers/gpu/drm/xe/xe_gt_pagefault.c:16: > > >> > drivers/gpu/drm/xe/xe_gt_types.h:102:25: note: at offset [1144, 265324] into destination object ‘tile’ of size 8 > > >> > 102 | struct xe_tile *tile; > > >> > | > > >> > > >> Which architecture? What compiler and version? Anything special in your build > > >> setup? I do x86_64 allmodconfig builds all day with gcc v13.2 and I don't see > > >> this failure. > > > > > >Good point! > > > > > >I am using gcc version 11.3.1 20230605 (Red Hat 11.4.1-2) on x86_64. > > >I see the same behavior on gcc version 8.5.0, which for all I know might > > >be too old. > > > > I could reproduce it with allmodconfig and gcc 11.4.1 from rockylinux, > > but not with gcc 9.3 or 12.3. Also it's not reproduced with gcc 11.4.1 > > when using defconfig + CONFIG_DRM_XE (even if -Wstringop-overflow is > > still added). > > > > I don't see a bug in the code, even if it inverts the head/tail > > convention. > > > > Searching around showed this which may be relevant: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101854 > > At least I can reproduce the same issue as in the snippet provided > > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101854#c7) with the buggy > > compiler. > > > > So, maybe the best thing to do for now is to disable -Wstringop-overflow > > for gcc < 12? > > > > > > ------8<----- > > diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile > > index 6952da8979ea..0433a3c6cbfd 100644 > > --- a/drivers/gpu/drm/xe/Makefile > > +++ b/drivers/gpu/drm/xe/Makefile > > @@ -17,7 +17,7 @@ subdir-ccflags-y += $(call cc-option, -Wunused-const-variable) > > subdir-ccflags-y += $(call cc-option, -Wpacked-not-aligned) > > subdir-ccflags-y += $(call cc-option, -Wformat-overflow) > > subdir-ccflags-y += $(call cc-option, -Wformat-truncation) > > -subdir-ccflags-y += $(call cc-option, -Wstringop-overflow) > > +subdir-ccflags-$(call gcc-min-version, 120000) += $(call cc-option, -Wstringop-overflow) > > subdir-ccflags-y += $(call cc-option, -Wstringop-truncation) > > # The following turn off the warnings enabled by -Wextra > > ifeq ($(findstring 2, $(KBUILD_EXTRA_WARN)),) > > ------8<----- This I did, thank you! > > and if we are tweaking the warnings, then do similarly in scripts/Makefile.extrawarn > > so it doesn't show up again with W=1 builds. Thoughts? But I failed to find anything similar in scripts/Makefile.extrawarn, so the failure persists. > The top level Makefile (in linux-next) has: > > #Currently, disable -Wstringop-overflow for GCC 11, globally. > KBUILD_CFLAGS-$(CONFIG_CC_NO_STRINGOP_OVERFLOW) += $(call cc-option, -Wno-stringop-overflow) > KBUILD_CFLAGS-$(CONFIG_CC_STRINGOP_OVERFLOW) += $(call cc-option, -Wstringop-overflow) > > and init/Kconfig has: > > # Currently, disable -Wstringop-overflow for GCC 11, globally. > config GCC11_NO_STRINGOP_OVERFLOW > def_bool y > > config CC_NO_STRINGOP_OVERFLOW > bool > default y if CC_IS_GCC && GCC_VERSION >= 110000 && GCC_VERSION < 120000 && GCC11_NO_STRINGOP_OVERFLOW > > config CC_STRINGOP_OVERFLOW > bool > default y if CC_IS_GCC && !CC_NO_STRINGOP_OVERFLOW > > So, what does "grep -E '(STRINGOP_OVERFLOW|GCC_VERSION)' .config" show for your > breaking build(s)? Here you go! CONFIG_GCC_VERSION=110400 CONFIG_GCC11_NO_STRINGOP_OVERFLOW=y CONFIG_CC_NO_STRINGOP_OVERFLOW=y Thanx, Paul
WARNING: multiple messages have this Message-ID (diff)
From: "Paul E. McKenney" <paulmck@kernel.org> To: Stephen Rothwell <sfr@rothwell.id.au> Cc: Lucas De Marchi <lucas.demarchi@intel.com>, Stephen Rothwell <sfr@canb.auug.org.au>, lucas.dimarchi@intel.com, linux-kernel@vger.kernel.org, intel-xe@lists.freedesktop.org Subject: Re: [BUG] allmodconfig build error in next-20240108 Date: Tue, 9 Jan 2024 14:45:56 -0800 [thread overview] Message-ID: <d61dfe52-9567-4f62-98f5-5c1e00cb4708@paulmck-laptop> (raw) In-Reply-To: <20240110081155.48bb0cbd@oak> On Wed, Jan 10, 2024 at 08:11:55AM +1100, Stephen Rothwell wrote: > Hi Lucas, > > On Tue, 9 Jan 2024 10:58:40 -0600 Lucas De Marchi <lucas.demarchi@intel.com> wrote: > > > > On Mon, Jan 08, 2024 at 03:15:23PM -0800, Paul E. McKenney wrote: > > >On Tue, Jan 09, 2024 at 09:57:57AM +1100, Stephen Rothwell wrote: > > >> Hi Paul, > > >> > > >> On Mon, 8 Jan 2024 13:33:36 -0800 "Paul E. McKenney" <paulmck@kernel.org> wrote: > > >> > > > >> > Recent -next trees get the following build error for allmodconfig builds: > > >> > > > >> > ------------------------------------------------------------------------ > > >> > > > >> > drivers/gpu/drm/xe/xe_gt_pagefault.c: In function ‘xe_guc_pagefault_handler’: > > >> > ./include/linux/fortify-string.h:57:33: error: writing 16 bytes into a region of size 0 [-Werror=stringop-overflow=] > > >> > 57 | #define __underlying_memcpy __builtin_memcpy > > >> > | ^ > > >> > ./include/linux/fortify-string.h:644:9: note: in expansion of macro ‘__underlying_memcpy’ > > >> > 644 | __underlying_##op(p, q, __fortify_size); \ > > >> > | ^~~~~~~~~~~~~ > > >> > ./include/linux/fortify-string.h:689:26: note: in expansion of macro ‘__fortify_memcpy_chk’ > > >> > 689 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ > > >> > | ^~~~~~~~~~~~~~~~~~~~ > > >> > drivers/gpu/drm/xe/xe_gt_pagefault.c:340:17: note: in expansion of macro ‘memcpy’ > > >> > 340 | memcpy(pf_queue->data + pf_queue->tail, msg, len * sizeof(u32)); > > >> > | ^~~~~~ > > >> > In file included from drivers/gpu/drm/xe/xe_device_types.h:17, > > >> > from drivers/gpu/drm/xe/xe_vm_types.h:16, > > >> > from drivers/gpu/drm/xe/xe_bo.h:13, > > >> > from drivers/gpu/drm/xe/xe_gt_pagefault.c:16: > > >> > drivers/gpu/drm/xe/xe_gt_types.h:102:25: note: at offset [1144, 265324] into destination object ‘tile’ of size 8 > > >> > 102 | struct xe_tile *tile; > > >> > | > > >> > > >> Which architecture? What compiler and version? Anything special in your build > > >> setup? I do x86_64 allmodconfig builds all day with gcc v13.2 and I don't see > > >> this failure. > > > > > >Good point! > > > > > >I am using gcc version 11.3.1 20230605 (Red Hat 11.4.1-2) on x86_64. > > >I see the same behavior on gcc version 8.5.0, which for all I know might > > >be too old. > > > > I could reproduce it with allmodconfig and gcc 11.4.1 from rockylinux, > > but not with gcc 9.3 or 12.3. Also it's not reproduced with gcc 11.4.1 > > when using defconfig + CONFIG_DRM_XE (even if -Wstringop-overflow is > > still added). > > > > I don't see a bug in the code, even if it inverts the head/tail > > convention. > > > > Searching around showed this which may be relevant: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101854 > > At least I can reproduce the same issue as in the snippet provided > > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101854#c7) with the buggy > > compiler. > > > > So, maybe the best thing to do for now is to disable -Wstringop-overflow > > for gcc < 12? > > > > > > ------8<----- > > diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile > > index 6952da8979ea..0433a3c6cbfd 100644 > > --- a/drivers/gpu/drm/xe/Makefile > > +++ b/drivers/gpu/drm/xe/Makefile > > @@ -17,7 +17,7 @@ subdir-ccflags-y += $(call cc-option, -Wunused-const-variable) > > subdir-ccflags-y += $(call cc-option, -Wpacked-not-aligned) > > subdir-ccflags-y += $(call cc-option, -Wformat-overflow) > > subdir-ccflags-y += $(call cc-option, -Wformat-truncation) > > -subdir-ccflags-y += $(call cc-option, -Wstringop-overflow) > > +subdir-ccflags-$(call gcc-min-version, 120000) += $(call cc-option, -Wstringop-overflow) > > subdir-ccflags-y += $(call cc-option, -Wstringop-truncation) > > # The following turn off the warnings enabled by -Wextra > > ifeq ($(findstring 2, $(KBUILD_EXTRA_WARN)),) > > ------8<----- This I did, thank you! > > and if we are tweaking the warnings, then do similarly in scripts/Makefile.extrawarn > > so it doesn't show up again with W=1 builds. Thoughts? But I failed to find anything similar in scripts/Makefile.extrawarn, so the failure persists. > The top level Makefile (in linux-next) has: > > #Currently, disable -Wstringop-overflow for GCC 11, globally. > KBUILD_CFLAGS-$(CONFIG_CC_NO_STRINGOP_OVERFLOW) += $(call cc-option, -Wno-stringop-overflow) > KBUILD_CFLAGS-$(CONFIG_CC_STRINGOP_OVERFLOW) += $(call cc-option, -Wstringop-overflow) > > and init/Kconfig has: > > # Currently, disable -Wstringop-overflow for GCC 11, globally. > config GCC11_NO_STRINGOP_OVERFLOW > def_bool y > > config CC_NO_STRINGOP_OVERFLOW > bool > default y if CC_IS_GCC && GCC_VERSION >= 110000 && GCC_VERSION < 120000 && GCC11_NO_STRINGOP_OVERFLOW > > config CC_STRINGOP_OVERFLOW > bool > default y if CC_IS_GCC && !CC_NO_STRINGOP_OVERFLOW > > So, what does "grep -E '(STRINGOP_OVERFLOW|GCC_VERSION)' .config" show for your > breaking build(s)? Here you go! CONFIG_GCC_VERSION=110400 CONFIG_GCC11_NO_STRINGOP_OVERFLOW=y CONFIG_CC_NO_STRINGOP_OVERFLOW=y Thanx, Paul
next prev parent reply other threads:[~2024-01-09 22:46 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-01-08 21:33 [BUG] allmodconfig build error in next-20240108 Paul E. McKenney 2024-01-08 21:33 ` Paul E. McKenney 2024-01-08 22:57 ` Stephen Rothwell 2024-01-08 22:57 ` Stephen Rothwell 2024-01-08 23:15 ` Paul E. McKenney 2024-01-08 23:15 ` Paul E. McKenney 2024-01-09 16:58 ` Lucas De Marchi 2024-01-09 16:58 ` Lucas De Marchi 2024-01-09 21:11 ` Stephen Rothwell 2024-01-09 21:11 ` Stephen Rothwell 2024-01-09 22:45 ` Paul E. McKenney [this message] 2024-01-09 22:45 ` Paul E. McKenney 2024-01-09 22:58 ` Stephen Rothwell 2024-01-10 1:09 ` Lucas De Marchi 2024-01-10 1:09 ` Lucas De Marchi 2024-01-10 3:46 ` Paul E. McKenney 2024-01-10 5:03 ` Stephen Rothwell 2024-01-10 10:26 ` Paul E. McKenney 2024-01-10 15:00 ` Lucas De Marchi 2024-01-10 15:00 ` Lucas De Marchi 2024-01-10 15:18 ` Jani Nikula 2024-01-10 15:21 ` Lucas De Marchi 2024-01-10 15:21 ` Lucas De Marchi 2024-01-10 16:00 ` Paul E. McKenney 2024-01-10 16:00 ` Paul E. McKenney 2024-01-09 18:08 ` ✗ CI.Patch_applied: failure for " Patchwork
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=d61dfe52-9567-4f62-98f5-5c1e00cb4708@paulmck-laptop \ --to=paulmck@kernel.org \ --cc=intel-xe@lists.freedesktop.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lucas.demarchi@intel.com \ --cc=lucas.dimarchi@intel.com \ --cc=sfr@canb.auug.org.au \ --cc=sfr@rothwell.id.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.