Re: gs_group_1 crashing on 13beta2/s390x

From: Andres Freund <andres(at)anarazel(dot)de>
To: Christoph Berg <myon(at)debian(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: gs_group_1 crashing on 13beta2/s390x
Date: 2020-10-16 03:27:02
Message-ID: 20201016032702.efsazsvgmu2jwfgs@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-10-15 17:12:54 -0700, Andres Freund wrote:
> On 2020-10-15 15:37:01 -0700, Andres Freund wrote:
> It's a bug that was fixed in LLVM 4, but too late to be backported to
> 3.9.
>
> The easiest seems to be to just use a wrapper function that does the
> necessary pre-checks. Something like the below (in llvmjit_wrap.cpp).
>
> Since the wrapper still needs to call into
> LLVMGetAttributeCountAtIndexPG, it seems easier to just use the seperate
> function name, rather than #define'ing LLVMGetAttributeCountAtIndex() to
> the PG version?
>
> /*
> * Like LLVM's LLVMGetAttributeCountAtIndex(), works around a bug in LLVM 3.9.
> *
> * In LLVM <= 3.9, LLVMGetAttributeCountAtIndex() segfaults if there are no
> * attributes at an index (fixed in LLVM commit ce9bb1097dc2).
> */
> unsigned
> LLVMGetAttributeCountAtIndexPG(LLVMValueRef F, uint32 Idx)
> {
> /*
> * This is more expensive, so only do when using a problematic LLVM
> * version.
> */
> #if LLVM_VERSION_MAJOR < 4
> if (!llvm::unwrap<llvm::Function>(F)->getAttributes().hasAttributes(Idx))
> return 0;
> #endif
>
> /*
> * There is no nice public API to determine the count nicely, so just
> * always fall back to LLVM's C API.
> */
> return LLVMGetAttributeCountAtIndex(F, Idx);
> }

Seems to have calmed the buildfarm, without negative consequences so far.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2020-10-16 03:32:08 Re: speed up unicode decomposition and recomposition
Previous Message Amit Kapila 2020-10-16 02:49:37 Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables