This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PR85817


On 05/18/2018 02:49 AM, Prathamesh Kulkarni wrote:
> Hi,
> In r260250, the condition
> 
> if (integer_zerop (retval))
>   continue;
> 
> was added before checking retval was of pointer type which caused
> functions having return type apart from void *, to be marked as
> malloc. The attached patch gets rid of the above check since we do not
> wish to mark function returning NULL as malloc.
> Also, it adds a check to return false if all args to phi are 0,
> although I am not sure if this'd actually trigger in practice since
> constant propagation should have folded the phi into constant 0
> already.
> 
> Bootstrap+test in progress on x86_64-linux-gnu and aarch64-linux-gnu.
> OK to commit if passes ?
So I just checked and it appears this will resolve the riscv64 issue.

The additional marking was ultimately causing the alias analysis code to
narrow the aliasing scope of a local variable that had its address taken
-- to the point where it was no longer considered escaping.

With the variable no longer escaping, calls were no longer may-defs of
the variable and Wuninitialized could perform a more precise analysis
and determined the variable was used potentially uninitialized.

In reality the uninitialized use is guarded in such a way that it won't
be used uninitialized, but without some kind of late inlining the
analysis wouldn't be able to see the use is properly guarded.

With the more restrictive marking, the variable is considered escaping
again and thus is may-def'd by random calls and we don't trigger the
-Wuninitialized warning anymore.


Thanks,
Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]