[cfe-dev] Addresses of referenced objects in clang 3.5

[Robinson, Paul]

Seems like there ought to be some kind of "unreachable" warning on the "return 0;" statement?
--paulr

From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of David Blaikie
Sent: Friday, September 19, 2014 7:25 AM
To: Martin Richtarsky; Nick Lewycky
Cc: cfe-dev Developers
Subject: Re: [cfe-dev] Addresses of referenced objects in clang 3.5


(+Nick who had a hand in implementing this optimization)

I don't think there's a flag to control this, no.
On Sep 19, 2014 1:47 AM, "Richtarsky, Martin" <martin.richtarsky at sap.com<mailto:martin.richtarsky at sap.com>> wrote:
Hi,

since clang 3.5 code as below is optimized away with -O1, assuming that the address of the object
can never be NULL:

class A { };

int func(A& a)
{
    if (&a)
    {
        return 1;
    }
    return 0;
}

int main()
{
    A &a = *reinterpret_cast<A *>(0);
    return func(a);
}

clang++ -Wall -O1  ptrnull.cpp -o ptrnull

ptrnull.cpp:5:10: warning: reference cannot be bound to dereferenced null pointer
in well-defined C++ code; pointer may be assumed to always convert to true [-Wundefined-bool-conversion]
    if (&a)
    ~~   ^
1 warning generated.


./ptrnull
Return code: 1

This is as described in the release notes.

When changing func() as follows the warning is not shown, but clang still performs
the same optimization. Shouldn't the warning be shown here aswell?

int func(A& a)
{
    A *aptr = &a;
    if (aptr)
    {
        return 1;
    }
    return 0;
}

Is it possible to disable this optimization specifically (without resorting to -O0)
to gradually fix codebases that rely on such checks? I saw that I can use
-fsanitize=null, which helps, but disabling the optimization would still
be the best temporary workaround.

Thanks and Best regards,
Martin


_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu<mailto:cfe-dev at cs.uiuc.edu>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140919/fc641ce1/attachment.html>