Spurious compiler warning ?

[kenji hara]

2011/11/4 Nick Sabalausky <a at a.a>:
> "kenji hara" <k.hara.pg at gmail.com> wrote in message
> news:mailman.655.1320322897.24802.digitalmars-d at puremagic.com...
>> 2011/11/3 Nick Sabalausky <a at a.a>:
>>> I don't know much about the internals of DMD, but would this make any
>>> sense?:
>>>
>>> When unrolling code, keep track of where the unrolled parts came from.
>>> Only
>>> issue an unreachable code warning if *all* the unrolled versions of the
>>> original line X are unreachable.
>>
>> First, when we use -w option, we usually want to show *all* warnings of
>> codes.
>> Isn't it your expects?
>>
>
> All real warnings, yes, but this one is just simply incorrect. The line *in
> the source code* that says "writeln( "A: ", member );"  *does*, in fact, get
> reached. Just because it doesn't get reached in *every* iteration doesn't
> change that fact that it *does* get reached and is therefore *not*
> unreachable code. The fact that the compiler unrolls it behind-the-scenes is
> irrelevent to the user - that merely explains why the warning is *currently*
> thrown, not why it *should* be thrown.
>
>> Second, each unrolled loop bodies is separately analyzable by the
>> compiler.
>> There is no reason to drop the detectable information, unless other
>> factors affect (such as performance).
>>
>> I don't know why you want to reduce warnings that (probably) you expects.
>>
>
> I don't see why anyone would ever expect this warning at all. *All* lines
> inside the user's foreach body *do* get used. It's the *compiler's* internal
> processing that *adds* in some dead code behind-the-scenes. The source
> doesn't have any dead code. It's just like inlining:
>
> int foo(int x)
> {
>    if(x > 5)
>        return 5;
>    return 1;
> }
>
> void main()
> {
>    int x;
>    x = foo(22);
> }
>
>
> Inlining could turn that into:
>
> void main()
> {
>    int x;
>    if(22 > 5)
>        x = 5;
>    else
>        x = 1;
> }
>
> Now you have dead code: "x = 1;". But nobody would ever expect to get an
> "unreachable code" warning from that. It would never even be helpful. It
> would always just be noise. Same goes for the OP's foreach example.
>
> In both this inlining example and the OP's example, what's important is
> whether any of the *user's* code is unreachable, not whether any of the
> compiler's internally-generated code is unreachable.

OK. You want to detect unreachable codes that *human feels* with -w.
I want to detect codes that is *computed* as unreachable.

I think that the -w option's Raison d'etre is to detect all of the
*potentially* unreachable codes.
For the purpose, -w should detect many codes as far as possible.
There is no reason to reduce information by merging unrolled loops.

> The fact that the compiler unrolls it behind-the-scenes is
irrelevent to the user

No, foreach with tuple always unrolled. It is basically truth in
strict-typed language.
Because each elements can have different types.

And with an unrolled loop, its body code does *small generative
programming*, and the generated codes may have unreachable statements.
Current -w is useful tool to terminate them.

Finally from compiler developer sight:
Current dmd uses same statically analyzer against unrolled and normal
loops. It has been the compiler implementation simple.

Kenji Hara