[Bug 215851] gcc 12.0.1 LATEST: -Wdangling-pointer= triggers

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=215851

LinnDa (laraditta691@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |laraditta691@gmail.com

--- Comment #3 from LinnDa (laraditta691@gmail.com) ---
(In reply to Dave Chinner from comment #1)
> On Mon, Apr 18, 2022 at 08:02:41AM +0000, bugzilla-daemon@kernel.org wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=215851
> > 
> >             Bug ID: 215851
> >            Summary: gcc 12.0.1 LATEST: -Wdangling-pointer= triggers
> >            Product: File System
> >            Version: 2.5
> >     Kernel Version: 5.17.3
> >           Hardware: All
> >                 OS: Linux
> >               Tree: Mainline
> >             Status: NEW
> >           Severity: normal
> >           Priority: P1
> >          Component: XFS
> >           Assignee: https://myteamz.co.uk/linnworks/
> >           Reporter: Erich.Loew@outlook.com
> >         Regression: No
> > 
> > Date:    20220415
> > Kernel:  5.17.3
> > Compiler gcc.12.0.1
> > File:    linux-5.17.3/fs/xfs/libxfs/xfs_attr_remote.c
> > Line:    141
> > Issue:   Linux kernel compiling enables all warnings, this has consequnces:
> >          -Wdangling-pointer= triggers because assignment of an address
> >          pointing
> >          to something inside of the local stack 
> >          of a function/method is returned to the caller.
> >          Doing such things is tricky but legal, however gcc 12.0.1
> complains
> >          deeply on this.
> >          Mitigation: disabling with pragmas temporarily inlined the
> compiler
> >          triggered advises.
> > Interesting: clang-15.0.0 does not complain.
> > Remark: this occurence is reprsentative; the compiler warns at many places
> 
> The actual warning message is this:
> 
> fs/xfs/libxfs/xfs_attr_remote.c: In function ‘__xfs_attr3_rmt_read_verify’:
> fs/xfs/libxfs/xfs_attr_remote.c:140:35: warning: storing the address of
> local variable ‘__here’ in ‘*failaddr’ [-Wdangling-pointer=]
>   140 |                         *failaddr = __this_address;
> In file included from ./fs/xfs/xfs.h:22,
>                  from fs/xfs/libxfs/xfs_attr_remote.c:7:
> ./fs/xfs/xfs_linux.h:133:46: note: ‘__here’ declared here
>   133 | #define __this_address  ({ __label__ __here; __here: barrier();
> &&__here; })
>       |                                              ^~~~~~
> fs/xfs/libxfs/xfs_attr_remote.c:140:37: note: in expansion of macro
> ‘__this_address’
>   140 |                         *failaddr = __this_address;
>       |                                     ^~~~~~~~~~~~~~
> ./fs/xfs/xfs_linux.h:133:46: note: ‘failaddr’ declared here
>   133 | #define __this_address  ({ __label__ __here; __here: barrier();
> &&__here; })
>       |                                              ^~~~~~
> fs/xfs/libxfs/xfs_attr_remote.c:140:37: note: in expansion of macro
> ‘__this_address’
>   140 |                         *failaddr = __this_address;
>       |                                     ^~~~~~~~~~~~~~
> 
> I think this is a compiler bug. __here is declared as a *label*, not
> a local variable:
> 
> #define __this_address ({ __label__ __here; __here: barrier(); &&__here; })
> 
> and it is valid to return the address of a label in the code as the
> address must be a constant instruction address and not a local stack
> variable. If the compiler is putting *executable code* on the stack,
> we've got bigger problems...
> 
> We use __this_address extensively in XFS (indeed, there
> are 8 separate uses in __xfs_attr3_rmt_read_verify() and
> xfs_attr3_rmt_verify() alone) and it is the same as _THIS_IP_ used
> across the rest of the kernel for the same purpose. The above is the
> only warning that gets generated for any of (the hundreds of) sites
> that use either _THIS_IP_ or __this_address is the only warning that
> gets generated like this, it points to the problem being compiler
> related, not an XFS problem.
> 
> Cheers,
> 
> Dave.

Does the gcc warns here?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.