[PING][BUG] -Wunreachable-code not working

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[PING][BUG] -Wunreachable-code not working

Eric Fiselier via cfe-dev
HI all,

I'm reporting this bug here since the LLVM Bugzilla requires
registering an account (which can't be done by myself manually).

Basically, this code triggers the warning:

int main()
{
    return 0;

    int a = 42;
}

while this doesn't:

#define A 42

int main()
{
    return 0;

    int a = A;
}

This happens on clang++-6.0. I'm not using any options other than
-Wunreachable-code.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [PING][BUG] -Wunreachable-code not working

Eric Fiselier via cfe-dev
I didn't look at these clang warnings specifically, so i might be
completely wrong, but i suspect that a lot of warnings are suppressed in
mere presence of macros. It is just too easy to produce weird code by
combining completely valid macros. Probably not the best example but
gives a rough idea:

   #ifdef WINDOWS
   #define SHOULD_USE_X 0
   #else
   #define SHOULD_USE_X shouldUseX();
   #endif

   if (SHOULD_USE_X) {
     // Should we emit a deadcode warning here under Windows?
   }

Such suppression might probably be made less brutal, but i'll be
surprised if it were possible to get away with not having it at all. And
it's pretty tricky to find deadcode before the preprocessor runs, when
you're still capable of accidentally concatenating 'ret' and 'urn' into
'return'. So it's not the most pleasant problem to solve, and it's
usually not that terrible when we don't give a warning (it's much less
terrible than emitting a warning that's not actionable), so people
usually make various suppressions for this sort of stuff.

On 4/12/18 1:55 PM, Martin Galvan via cfe-dev wrote:

> HI all,
>
> I'm reporting this bug here since the LLVM Bugzilla requires
> registering an account (which can't be done by myself manually).
>
> Basically, this code triggers the warning:
>
> int main()
> {
>      return 0;
>
>      int a = 42;
> }
>
> while this doesn't:
>
> #define A 42
>
> int main()
> {
>      return 0;
>
>      int a = A;
> }
>
> This happens on clang++-6.0. I'm not using any options other than
> -Wunreachable-code.
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [PING][BUG] -Wunreachable-code not working

Eric Fiselier via cfe-dev
2018-04-12 22:53 GMT-03:00 Artem Dergachev <[hidden email]>:
> Such suppression might probably be made less brutal, but i'll be surprised
> if it were possible to get away with not having it at all. And it's pretty
> tricky to find deadcode before the preprocessor runs, when you're still
> capable of accidentally concatenating 'ret' and 'urn' into 'return'. So it's
> not the most pleasant problem to solve, and it's usually not that terrible
> when we don't give a warning (it's much less terrible than emitting a
> warning that's not actionable), so people usually make various suppressions
> for this sort of stuff.

Agreed, but wouldn't it make more sense that the dead code
identification happened after the preprocessor is done? I know nothing
of clang internals, that's just what makes sense to me.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [PING][BUG] -Wunreachable-code not working

Eric Fiselier via cfe-dev


On 4/13/18 7:48 AM, Martin Galvan wrote:

> 2018-04-12 22:53 GMT-03:00 Artem Dergachev <[hidden email]>:
>> Such suppression might probably be made less brutal, but i'll be surprised
>> if it were possible to get away with not having it at all. And it's pretty
>> tricky to find deadcode before the preprocessor runs, when you're still
>> capable of accidentally concatenating 'ret' and 'urn' into 'return'. So it's
>> not the most pleasant problem to solve, and it's usually not that terrible
>> when we don't give a warning (it's much less terrible than emitting a
>> warning that's not actionable), so people usually make various suppressions
>> for this sort of stuff.
> Agreed, but wouldn't it make more sense that the dead code
> identification happened after the preprocessor is done? I know nothing
> of clang internals, that's just what makes sense to me.

Then it'd produce false alarms on the "WINDOWS" example i posted
previously. It is inevitable that a deeper analysis that involves
exploring both a fully constructed syntax tree and rich preprocessor
information is necessary. Clang does provide such information, but
probably the deeper analysis is not implemented beyond the "hmm there's
a macro, let's silence the warning" level of ingenuity.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [PING][BUG] -Wunreachable-code not working

Eric Fiselier via cfe-dev


> On Apr 13, 2018, at 2:43 PM, Artem Dergachev via cfe-dev <[hidden email]> wrote:
>
>
>
> On 4/13/18 7:48 AM, Martin Galvan wrote:
>> 2018-04-12 22:53 GMT-03:00 Artem Dergachev <[hidden email]>:
>>> Such suppression might probably be made less brutal, but i'll be surprised
>>> if it were possible to get away with not having it at all. And it's pretty
>>> tricky to find deadcode before the preprocessor runs, when you're still
>>> capable of accidentally concatenating 'ret' and 'urn' into 'return'. So it's
>>> not the most pleasant problem to solve, and it's usually not that terrible
>>> when we don't give a warning (it's much less terrible than emitting a
>>> warning that's not actionable), so people usually make various suppressions
>>> for this sort of stuff.
>> Agreed, but wouldn't it make more sense that the dead code
>> identification happened after the preprocessor is done? I know nothing
>> of clang internals, that's just what makes sense to me.
>
> Then it'd produce false alarms on the "WINDOWS" example i posted previously. It is inevitable that a deeper analysis that involves exploring both a fully constructed syntax tree and rich preprocessor information is necessary. Clang does provide such information, but probably the deeper analysis is not implemented beyond the "hmm there's a macro, let's silence the warning" level of ingenuity.

Yes, this is exactly right.

I think the fix here would be to try to make the silencing ask whether *everything* about the dead statement is a macro instantiation rather than *anything*.

John.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev