On Wed, May 7, 2014 at 2:28 PM, Florian Weimer <fwei...@redhat.com> wrote:
> On 05/07/2014 02:11 PM, Richard Biener wrote:
>
>>> Precisely. But optimizing this:
>>>
>>>
>>> int main()
>>> {
>>> if (0)
>>> foo ();
>>> else
>>> throw std::logic_error ("error");
>>> bar ();
>>> }
>>>
>>> to:
>>>
>>> int main()
>>> {
>>> throw std::logic_error ("error");
>>> bar ();
>>> }
>>>
>>> would cause the code to issue such unwanted warnings. That's why I need
>>> access to these trivial if statements.
>>
>>
>> I don't think it would. bar () would be gone already as throw doesn't
>> return.
>
>
> Fair point. So here's a different example:
>
>
> int main()
> {
> if (0)
> foo ();
> else
> throw std::logic_error ("always reachable");
> throw std::logic_error ("maybe reachable (no warning)");
> throw std::logic_error ("not reachable, warning required");
> }
>
> I think this also applies to other warnings such as missing null pointer
> checks. We still want to report them for code unreachable after (some)
> optimization, just like we report type errors there.
>
> The more challenging issue with early GIMPLE is that loops have already been
> lowered to gotos, so adopting the syntax-based Java reachability rules is
> impossible. Oh dear.
Perfect is the enemy of the good (no false positives and no false
negatives). I don't think you can get all you want starting at GIMPLE.
And the "earlier" you start the more you need to implement a whole compiler.
And you have of course to precisely define what you consider
"unreachable" (considering a global const bool debug = true/false; and
if (debug) guarded code - compared to using the preprocessor).
Richard.
