[LLVMdev] readonly and infinite loops

[Finkel, Hal J.]

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.

-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150627/fd06cade/attachment.html>