On 2/9/22 03:30, Richard Biener wrote:
On Tue, Feb 8, 2022 at 11:38 PM Jason Merrill via Gcc-patches
<gcc-patches@gcc.gnu.org> 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.
+ tree var = SSA_NAME_VAR (lhs_ref.ref);
+ if (DECL_BY_REFERENCE (var))
I think you need to test var && TREE_CODE (var) == PARM_DECL here since
for DECL_BY_REFERENCE RESULT_DECL we _do_ escape to the caller. Also
SSA_NAME_VAR var might be NULL.
+ /* 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 think points-to analysis got this correct when the reference was marked
restrict but now it also fails at this, making DSE fail to eliminate the
store in
struct A { A(); ~A(); int *p; };
void foo (struct A a, int *p)
{
a.p = p;
}
Well, that's conservatively correct; since we don't know the definition
of ~A, we don't know whether it copies p somewhere, e.g.
int *global_p;
A::~A() { global_p = p; }
in which case eliminating the store would be an invalid optimization,
just as it would be if 'a' were a local variable.
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).
