[tools] improve check-iwyu script

See merge request flowpack/manycore/emper!6

Bump CI

See merge request flowpack/manycore/emper!4

Turns out, 410cd9d1 ("[Continuation] Fix setJmp() by adding 'rax'
to clobber list") was not enough for GCC 14 (probably newer
ones). This time, the compiler (GCC 14.2.0) also failed to re-load
%rax after the setJmp() and also seemed to perform optimizations based
on the assumption that setJmp() would *always* return 0.

It appears

asm("nop" ::: "rax", "rbx", "r12", "r13", "r14", "r15", "memory");

in Continuation::setJmp() is now, after we added the 'noipa'
attribute, also no longer necessary. But we keep it for now.

Add a, simple for now, test for EMPER's low-level Continuation API.

sudo may not be available in the image, and runuser is preferred for
this use-case anyway.

Newer flowdalic/gentoo-dev images have ENTRYPIONT specified, this
prevents arguments from being passed to the docker run entrypoint,
which is tools/docker-prepare in case of docker.sh.

To fix that, we invoke "docker run" with "--entrypoint
tools/docker-preapre" in docker.sh.

Florian Schmaus authored 3 months ago and Florian Schmaus committed 3 months ago

Sadly, gitlab-runner does no longer support the "exec" command, so we
have to use gitlab-ci-local as alternative.

Using the emper::log facility adds a timestamp and worker ID to the
printed message.

Add WaitFreeCountingSemaphore

See merge request !415

Various fixes and improvements

See merge request !421

Add missing "goto loop" to CL Queues

See merge request !418

Fix Continuation::setJmp()

See merge request !420

The previously used 'membar' macro does not have 'rax' in its clobber
list. As result, a compiler may not reload the contents of 'rax' after
the setJmp() call and instead 'cache' eax's value. However, 'rax' is
used to pass the jump's value once we perfrom a long jump. Therefore,
it should be part of the clobber list of setJmp().

In fact, GCC 14 started to perform an optimization in this case,
causing Fibril synchronization to fail, as the passed
fibrilResumeValue became 0.

Compare the following code of ContextManager::start()

GCC 13:
3f40d:   e8 2e e8 fd ff          call   1dc40 <Continuation::setJmp()::{lambda(Continuation*)#1}::operator()(Continuation*) const@plt>
3f412:   89 44 24 04             mov    %eax,0x4(%rsp)
3f416:   48 98                   cltq
3f418:   48 89 44 24 08          mov    %rax,0x8(%rsp)
3f41d:   90                      nop

GCC 14:
3f8ea:   e8 81 e2 fd ff          call   1db70 <Continuation::setJmp()::{lambda(Continuation*)#1}::operator()(Continuation*) const@plt>
3f8ef:   90                      nop

As we can see, GCC 14 does not (re-)load eax back to its stack
position after the setJmp().

If we reach this code with fibrilResumeValue == 0, then something went
wrong (as it did with gcc-14, but that is solved in a later commit).

eval/BFP9000: create latencies_sorted, always mention units, alloc in constructor

See merge request !419

If maxRetries is set, then actually retry the popTop() operation.

eval/BFP9000: record csv

See merge request !417

The binary fails if the fibril is synced implicitly over its
destructor. It appears that after membar(doSync()), the base pointer
is wrong, causing the subsequent "reverseStealCount = 0" in
syncWaitFree() to write to unallocate memory. I am not sure yet why,
but this works around the issue.