Small coroutine class
I think you need to document your assumptions and/or intended use cases a little better. Right now, I don't see how anything based on setjmp/longjmp could actually implement a coroutine, since longjmp can only ever jump upward in the call-stack, never downward. (Really, it can't jump "downward" because there is no "downward": the only things below us on the call-stack are things that have already finished executing, and things which will execute in the future.)

Notice that "things which will execute in the future" includes "interrupt handlers". You might want to check whether your implementation plays well with Unix signal handlers — I suspect it does not.



alloca(top - (stack_ + N));


This is a red flag: you're calling alloca without assigning the result anywhere. A sufficiently smart compiler will just optimize away this useless call. (Yeah, I kinda get what you're trying to do... but the compiler is under no obligation to get it.) What you really need to do here is heap-allocate a buffer for your stack, and then somehow get the saved stack pointer in the jmp_buf to point to it.

And I only kinda see what you're doing here, anyway. Are you assuming that the coroutine object itself must be allocated on the stack? What happens if I make a global or static coroutine object?



[this, f = ::std::forward&lt;F&gt;(f)](A&amp;&amp; ...a) __attribute__ ((noinline))


The __attribute__((noinline)) here is another red flag. This time I don't get what you're trying to do. What would break if this lambda's operator() got inlined?

Also, style nit: I've never seen anyone put a space after the word __attribute__ before.



Other style nits:

auto running() const noexcept


auto is a strange way to spell bool. It's not saving you any bytes.

// else do nothing


The above comment is highly misleading, in that it's followed by 13 lines of really dense code — hardly "do nothing"! I'd delete that comment.

auto top(reinterpret_cast&lt;char*&gt;(&amp;top));


I'm actually amazed that this works, given that the decltype of &amp;top is not known at the time the RHS is parsed. ...Oh wait, yeah, it doesn't work. Both GCC and Clang reject this code.

for (int i{}; i != 3; ++i)


Kudos for using prefix increment. Everything else about this for-loop is pretty unusual, though. I strongly recommend looping over the range [0,3) like this instead:

for (int i = 0; i &lt; 3; ++i)




API design suggestions:


Empty angle brackets suck. I'd recommend something more like

template &lt;size_t N&gt; class coroutine_with_size { ... }

using coroutine = coroutine_with_size&lt;4096&gt;;

It's unfortunate that your coroutine has to do all its own I/O; a better design would be like the one found in Javascript (and Python), where coroutines can yield values. Unfortunately, the ability to yield values causes a cascade of API changes. Look:

c.run([](auto&amp;&amp; c) {
    for (int i = 0; i &lt; 3; ++i) {
        c.yield(i);
    }
});

while (c.running())
{
    int ii = c.resume();
    std::cout &lt;&lt; ii &lt;&lt; std::endl;
}



Well, unless c is somehow "looking ahead" to determine the value it's going to return next time, c.running() doesn't really make sense anymore. We've got to have c.resume() do all the hard work, at which point we need a way to say "okay, no more data, please stop iterating". That is, we need a way for c.resume() to terminate execution but not return a value. This smells like an exception. So:

c.run([](auto&amp;&amp; c) {
    for (int i = 0; i &lt; 3; ++i) {
        c.yield(i);
    }
});

while (true)
{
    try {
        int ii = c.resume();
        std::cout &lt;&lt; ii &lt;&lt; std::endl;
    } catch (const coroutine::done&amp;) {
        break;
    }
}


But now what is c.run() actually doing? It can't be actually starting to run the provided lambda, because there's nowhere for us to stash the yielded result yet (we haven't gotten to ii's declaration). So all it's really doing now is constructing the coroutine object and then returning immediately. That smells like a constructor. So:

auto c = coroutine([](auto&amp;&amp; c) {
    for (int i = 0; i &lt; 3; ++i) {
        c.yield(i);
    }
});

while (true)
{
    try {
        int ii = c.resume();
        std::cout &lt;&lt; ii &lt;&lt; std::endl;
    } catch (const coroutine::done&amp;) {
        break;
    }
}


And unfortunately now we've got move-constructible coroutine objects, and your entire implementation strategy falls apart even more than it had been. Crap!



...Speaking of which, your current implementation provides defaulted copy and move constructors! You should definitely delete those:

coroutine(const coroutine&amp;) = delete;
coroutine&amp; operator=(const coroutine&amp;) = delete;
// move operations get deleted implicitly due to the above;
// but I wouldn't object to deleting them explicitly as well




Getting back to the API-design example: the next step in a Javascript-like design would be allowing c.resume() to take input values, as well as yielding output values. Mind you, I'm not sure what the implementation for this would look like in C++. It might not be 100% possible. :)

auto c = coroutine([](auto&amp;&amp; c, int step) {
    for (int i = 0; i &lt; 3; i += step) {
        step = c.yield(i);
    }
});

while (true)
{
    try {
        int ii = c.resume(1);
        std::cout &lt;&lt; ii &lt;&lt; std::endl;
    } catch (const coroutine::done&amp;) {
        break;
    }
}


EDIT: Okay, I think it's not 100% possible — not without templating the coroutine class on the "inputs" and "outputs" (args-to-resume and args-to-yield) that it expects. I've done my own toy implementation here for comparison. Muddling through that implementation also helped me understand the undefined-behavior magic about which I complained at the top of this review.



At least in the trivial case you started with — a coroutine used only as a generator, and whose c.resume() takes no input values — it would make sense to provide a sort of coroutine_generator_iterator so that one could write simply

for (int ii : coroutine_generator_iterator(c)) {
    std::cout &lt;&lt; ii &lt;&lt; std::endl;
}


This coroutine_generator_iterator concept wouldn't be very useful for coroutines that were actually used as coroutines, e.g. passing control back and forth. But it's definitely a good idea if you're just trying to do Python-style generator functions in C++.