Spurious compiler warning ?

[Marco Leise]

Am 03.11.2011, 17:21 Uhr, schrieb kenji hara <k.hara.pg at gmail.com>:

> 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

I don't understand why you want it to behave like this. Like Nick, I think  
the loop-unrolling or inlining should be transparent and not issue  
warnings that aren't understandable from the code at hand. And second the  
compiler should be free to remedy the situation itself by removing the  
dead code it just generated :p God damn, isn't that just obvious?