Bug 2165898 - gcc reports false warnings in kernel compile (Wdangling-pointer=)
Summary: gcc reports false warnings in kernel compile (Wdangling-pointer=)
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: gcc
Version: 9.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Marek Polacek
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-01-31 12:37 UTC by Prarit Bhargava
Modified: 2023-07-18 14:25 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-02-15 14:14:11 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 106080 0 P3 ASSIGNED Labels as values triggering -Wdangling-pointer 2023-02-15 14:10:50 UTC
Red Hat Issue Tracker RHELPLAN-147023 0 None None None 2023-01-31 12:38:42 UTC

Description Prarit Bhargava 2023-01-31 12:37:50 UTC
Description of problem: Enabling -Werror on the centos-stream-9/RHEL9 kernel compile results in false "-Werror=dangling-pointer" errors


Version-Release number of selected component (if applicable): centos-stream-9/RHEL9 latest



How reproducible: 100%


Steps to Reproduce:
1. Compile centos-stream-9/RHEL kernel with -Werror (see MR link below)

Actual results:  

See build artifacts from: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/1955

For example, on aarch64:

00:00:17 + perl -p -i -e 's/^CONFIG_BUILD_SALT.*/CONFIG_BUILD_SALT="5.14.0-247.1955_761091570.el9.aarch64"/' .config
00:00:17 + /usr/bin/make CROSS_COMPILE=aarch64-linux-gnu- -s HOSTCFLAGS= HOSTLDFLAGS= ARCH=arm64 'KCFLAGS= ' WITH_GCOV=0 -j24 Image.gz
00:04:23 + '[' 1 -eq 1 ']'
00:04:23 + /usr/bin/make CROSS_COMPILE=aarch64-linux-gnu- -s HOSTCFLAGS= HOSTLDFLAGS= ARCH=arm64 'KCFLAGS= ' WITH_GCOV=0 -j24 modules
00:05:59 fs/xfs/libxfs/xfs_attr_remote.c: In function ‘__xfs_attr3_rmt_read_verify’:
00:05:59 fs/xfs/libxfs/xfs_attr_remote.c:140:35: error: storing the address of local variable ‘__here’ in ‘*failaddr’ [-Werror=dangling-pointer=]
00:05:59   140 |                         *failaddr = __this_address;
00:05:59 In file included from ./fs/xfs/xfs.h:22,
00:05:59                  from fs/xfs/libxfs/xfs_attr_remote.c:7:
00:05:59 ./fs/xfs/xfs_linux.h:132:46: note: ‘__here’ declared here
00:05:59   132 | #define __this_address  ({ __label__ __here; __here: barrier(); &&__here; })
--
00:05:59       |                                              ^~~~~~
00:05:59 fs/xfs/libxfs/xfs_attr_remote.c:140:37: note: in expansion of macro ‘__this_address’
00:05:59   140 |                         *failaddr = __this_address;
00:05:59       |                                     ^~~~~~~~~~~~~~



Expected results: No warnings


Additional info: After a discussion with esandeen, the xfs maintainer, these warnings are false.  This is a gcc bug and not an issue with the kernel:

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

Comment 1 Marek Polacek 2023-01-31 14:49:54 UTC
Could we get a preprocessed source file?  You can obtain that by adding -save-temps to the compile flags line, it should produce xfs_attr_remote.i.

It could be one of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=Wdangling-pointer

So this is the system RHEL9 gcc11?  Does it only happen on aarch64?

Comment 2 Prarit Bhargava 2023-02-14 13:46:55 UTC
Hey Marek, sorry for the late reply.

(In reply to Marek Polacek from comment #1)
> Could we get a preprocessed source file?  You can obtain that by adding
> -save-temps to the compile flags line, it should produce xfs_attr_remote.i.

I will add this file as the next comment to this BZ.

> 
> It could be one of
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=Wdangling-pointer
> 

Yes, that's what I thought, however after staring at the code it doesn't look like the code is wrong, and that is confirmed by sandeen the maintainer of XFS.  Additionally there isn't an upstream resolution for this either.  I came across a commit (which I frustratingly cannot find) in which someone disabled the dangling pointer check in their driver so it seems others may have hit this issue as well.

> So this is the system RHEL9 gcc11?  Does it only happen on aarch64?

It seems to happen on aarch64 and 

https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/trusted-artifacts/762903479/build%20aarch64/3689672654/artifacts/build.log

and s390x

https://s3.amazonaws.com/arr-cki-prod-trusted-artifacts/trusted-artifacts/762903479/build%20s390x/3689672668/artifacts/build.log

P.

Comment 4 Marek Polacek 2023-02-14 16:06:03 UTC
Thanks for the .i file.  Unfortunately this seems to be reproducible with trunk as well.
aarch64 cross:

$ ./cc1 -quiet xfs_attr_remote.i -Iinclude -O2 -Wdangling-pointer
fs/xfs/libxfs/xfs_attr_remote.c: In function ‘__xfs_attr3_rmt_read_verify’:
fs/xfs/libxfs/xfs_attr_remote.c:140:14: warning: storing the address of local variable ‘__here’ in ‘*failaddr’ [-Wdangling-pointer=]
fs/xfs/libxfs/xfs_attr_remote.c:140:37: note: ‘__here’ declared here
fs/xfs/libxfs/xfs_attr_remote.c:140:37: note: ‘failaddr’ declared here

so I think I'll have to open an upstream PR and close this BZ, because I have nothing to backport.

Comment 5 Marek Polacek 2023-02-15 14:14:11 UTC
This is upstream PR106080 which I just fixed for GCC 13 [1], and plan to backport to GCC 12.
However: I don't plan any further DTS/GTS 12 updates (they would need exception+), and
GCC 11 doesn't have -Wdangling-pointer at all.  So I'm confused; you must have used GCC
12 rather than the system RHEL9 GCC 11.

[1] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d482b20fd346482635a770281a164a09d608b058


Note You need to log in before you can comment on or make changes to this bug.