Pinging the two patches here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590230.html
On 2/10/22 16:04, Martin Sebor wrote:
On 2/8/22 15:37, Jason Merrill wrote:
On 2/8/22 16:59, Martin Sebor wrote:
Transforming a by-value arguments to by-reference as GCC does for some
class types can trigger -Wdangling-pointer when the argument is used
to store the address of a local variable. Since the stored value is
not accessible in the caller the warning is a false positive.
The attached patch handles this case by excluding PARM_DECLs with
the DECL_BY_REFERENCE bit set from consideration.
While testing the patch I noticed some instances of the warning are
uninitentionally duplicated as the pass runs more than once. To avoid
that, I also introduce warning suppression into the handler for this
instance of the warning. (There might still be others.)
The second test should verify that we do warn about returning 't' from
a function; we don't want to ignore the DECL_BY_REFERENCE RESULT_DECL.
The indirect aggregate case isn't handled and needs more work but
since you brought it up I thought I should look into finishing it.
The attached patch #2 adds support for it. It also incorporates
Richard's suggestion to test PARM_DECL. Patch #2 applies on top
of patch #1 which is unchanged from the first revision.
I have retested it on x86_64-linux and by building Glibc and
Binutils + GDB.
If now is too late for the aggregate enhancement I'm okay with
deferring it until stage 1.
+ tree var = SSA_NAME_VAR (lhs_ref.ref);
+ if (DECL_BY_REFERENCE (var))
+ /* Avoid by-value arguments transformed into by-reference. */
+ continue;
I wonder if we can we express this property of invisiref parms
somewhere more general? I imagine optimizations would find it useful
as well. Could pointer_query somehow treat the reference as pointing
to a function-local object?
I don't quite see where in the pointer_query class this would be
useful (the class also isn't used for optimization). I could add
a helper to the access_ref class to query this property in warning
code but as this is the only potential client I'm also not sure
that's quite what you had in mind. I'd need some guidance as to
what you're thinking of here.
Martin
I previously tried to express this by marking the reference as
'restrict', but that was wrong
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474).
Jason
