[LLVMdev] readonly and infinite loops

[Sanjoy Das]

On Sat, Jun 27, 2015 at 3:36 PM, Finkel, Hal J. <hfinkel at anl.gov> wrote:
> No; the standard says that we get to assume that the loop will eventually
> terminate, or do I/O, or a few other possible things. I can find the text
> for you later if you'd like.

Actually, I'm more interested in what LLVM (not C/C++) says about
"while(1);" loops.  Such loops are legal in Java (and possibly other
languages that use LLVM) so it's problematic if LLVM specifies them to
have UB.

-- Sanjoy





>
> -Hal
>
> Sent from my Verizon Wireless 4G LTE DROID
>
>
> Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
>
> On Sat, Jun 27, 2015 at 2:16 PM, Nuno Lopes <nunoplopes at sapo.pt> wrote:
>> At least in C/C++ that's UB, yes.
>
> So you cannot map every turing machine to a valid C/C++ program then. :)
>
> Also, does this mean that "daemon" programs that run continuously till
> they're killed by the OS (using a mechanism that is not visible in C)
> are effectively undefined?
>
> -- Sanjoy
>
>> Some years ago there was a lot of discussion about this on the ML.  Se
>> Nick's patch, for example:
>>
>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100705/103670.html
>> The patch was eventually dropped, I don't recall why.  I think it's fine
>> to
>> assume that readnone functions always terminate.  It would probably fine
>> for
>> readonly functions as well.
>>
>> Nuno
>>
>>
>> -----Original Message-----
>> From: Sanjoy Das
>> Sent: Saturday, June 27, 2015 9:29 PM
>> Subject: [LLVMdev] readonly and infinite loops
>>
>> Running -early-cse on
>>
>> declare void @rn() readnone nounwind
>>
>> define void @f() {
>> entry:
>>  call void @rn()
>>  ret void
>> }
>>
>> removes the call to @rn().  But @rn() could have had an infinite loop
>> in it in which case @f() went from being a non-terminating
>> program to an terminating no-op.  Is this intentional?
>>
>> The only way I can see this transform being legal is if infinite loops
>> are declared to have undefined behavior, but I could not find anything
>> in the LLVM specification that mentions this.
>>
>> -- Sanjoy
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev