Thread: Latest LLVM breaks our code again

Latest LLVM breaks our code again

From
Tom Lane
Date:
Speaking of buildfarm breakage, seawasp has been failing for the
past several days.  It looks like bleeding-edge LLVM has again
changed some APIs we depend on.  First failure is here:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=seawasp&dt=2022-01-28%2000%3A17%3A48

            regards, tom lane



Re: Latest LLVM breaks our code again

From
Thomas Munro
Date:
On Mon, Jan 31, 2022 at 3:38 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Speaking of buildfarm breakage, seawasp has been failing for the
> past several days.  It looks like bleeding-edge LLVM has again
> changed some APIs we depend on.  First failure is here:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=seawasp&dt=2022-01-28%2000%3A17%3A48

Oops, I missed this message.  The patch at
https://www.postgresql.org/message-id/CA%2BhUKG%2BaGPBkBT5_4czkvzMu6-D%2BJgPaVL7mX_WBPXgGRndtXA%40mail.gmail.com
fixes the first two of these problems, and the third needs some more
work:

1.  There's a missing #include <new> (must have been transitively
included before).
2.  There's an API change that I'd written about already but hadn't
committed yet because seawasp is running behind my laptop at tracking
LLVM and I figured we might as well 'nagel' these kinds of commits.
3.  We'll need to look into how to switch LLVMBuildCall -> LLVMBuildCall2 etc.



Re: Latest LLVM breaks our code again

From
Fabien COELHO
Date:
> Speaking of buildfarm breakage, seawasp has been failing for the
> past several days.  It looks like bleeding-edge LLVM has again
> changed some APIs we depend on.  First failure is here:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=seawasp&dt=2022-01-28%2000%3A17%3A48

Indeed.

I'm sorry for the late warning: clang could not compile with its previous 
version at some point so my weekly recompilation got stuck and I did not 
notice for some months. I repaired by switching compiling clang with gcc 
instead. ::sigh::

-- 
Fabien.



Re: Latest LLVM breaks our code again

From
Andres Freund
Date:
Hi,

On 2022-01-30 21:38:16 -0500, Tom Lane wrote:
> Speaking of buildfarm breakage, seawasp has been failing for the
> past several days.  It looks like bleeding-edge LLVM has again
> changed some APIs we depend on.  First failure is here:

I'm doubtful that tracking development branches of LLVM is a good
investment. Their development model is to do changes in-tree much more than we
do. Adjusting to API changes the moment they're made will often end up with
further changes to the same / related lines.  Once they open the relevant
release-NN branch, it's a different story.

Maybe it'd make sense to disable --with-llvm on seawasp and have a separate
animal that tracks the newest release branch?

Greetings,

Andres Freund



Re: Latest LLVM breaks our code again

From
Fabien COELHO
Date:
Hello Andres,

> I'm doubtful that tracking development branches of LLVM is a good
> investment. Their development model is to do changes in-tree much more than we
> do. Adjusting to API changes the moment they're made will often end up with
> further changes to the same / related lines.  Once they open the relevant
> release-NN branch, it's a different story.
>
> Maybe it'd make sense to disable --with-llvm on seawasp>
> and have ppppppa separate animal that tracks the newest release branch?

The point of seawasp is somehow to have an early warning of upcoming 
changes, especially the --with-llvm part. LLVM indeed is a moving target, 
but they very rarely back down on their API changes… As pg version are 
expected to run for 5 years, they will encounter newer compiler versions, 
so being as ready as possible seems worthwhile.

ISTM that there is no actual need to fix LLVM breakage on the spot, but I 
think it is pertinent to be ok near release time. This is why there is a 
"EXPERIMENTAL" marker in the system description. There can be some noise 
when LLVM development version is broken, this has happened in the past 
with seawasp (llvm) and moonjelly (gcc), but not often.

About tracking releases: this means more setups and runs and updates, and 
as I think they do care about compatibility *within* a release we would 
not see breakages so it would not be very useful, and we would only get 
the actual breakages at LLVM release time, which may be much later.

For these reasons, I'm inclined to let seawasp as it is.

-- 
Fabien.

Re: Latest LLVM breaks our code again

From
Andres Freund
Date:
Hi,

On 2022-02-03 10:44:11 +0100, Fabien COELHO wrote:
> > I'm doubtful that tracking development branches of LLVM is a good
> > investment. Their development model is to do changes in-tree much more than we
> > do. Adjusting to API changes the moment they're made will often end up with
> > further changes to the same / related lines.  Once they open the relevant
> > release-NN branch, it's a different story.
> >
> > Maybe it'd make sense to disable --with-llvm on seawasp>
> > and have ppppppa separate animal that tracks the newest release branch?
>
> The point of seawasp is somehow to have an early warning of upcoming
> changes, especially the --with-llvm part. LLVM indeed is a moving target,
> but they very rarely back down on their API changes…

The point is less backing down, but making iterative changes that require
changing the same lines repeatedly...


> About tracking releases: this means more setups and runs and updates, and as
> I think they do care about compatibility *within* a release we would not see
> breakages so it would not be very useful, and we would only get the actual
> breakages at LLVM release time, which may be much later.

LLVM's release branches are created well before the release. E.g 13 was afaics
branched off 2021-07-27 [1], released 2021-09-30 [2].


> For these reasons, I'm inclined to let seawasp as it is.

I find seawasp tracking the development trunk compilers useful. Just not for
--with-llvm. The latter imo *reduces* seawasp's, because once there's an API
change we can't see whether there's e.g. a compiler codegen issue leading to
crashes or whatnot.

What I was proposing was to remove --with-llvm from seawasp, and have a
separate animal tracking the newest llvm release branch (I can run/host that
if needed).

Greetings,

Andres Freund

[1] git show $(git merge-base origin/release/13.x origin/main)
[2] git show llvmorg-13.0.0



Re: Latest LLVM breaks our code again

From
Thomas Munro
Date:
On Fri, Feb 4, 2022 at 8:12 AM Andres Freund <andres@anarazel.de> wrote:
> On 2022-02-03 10:44:11 +0100, Fabien COELHO wrote:
> > For these reasons, I'm inclined to let seawasp as it is.

It might be easier to use the nightly packages at
https://apt.llvm.org/.  You could update daily and still save so much
CPU that ...

> I find seawasp tracking the development trunk compilers useful. Just not for
> --with-llvm. The latter imo *reduces* seawasp's, because once there's an API
> change we can't see whether there's e.g. a compiler codegen issue leading to
> crashes or whatnot.
>
> What I was proposing was to remove --with-llvm from seawasp, and have a
> separate animal tracking the newest llvm release branch (I can run/host that
> if needed).

... you could do a couple of variations like that ^ on the same budget :-)

FWIW 14 just branched.  Vive LLVM 15.