Re: gs_group_1 crashing on 13beta2/s390x - Mailing list pgsql-hackers

From Andres Freund
Subject Re: gs_group_1 crashing on 13beta2/s390x
Date
Msg-id 20201016032702.efsazsvgmu2jwfgs@alap3.anarazel.de
Whole thread Raw
In response to Re: gs_group_1 crashing on 13beta2/s390x  (Andres Freund <andres@anarazel.de>)
List 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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Next
From: Michael Paquier
Date:
Subject: Re: speed up unicode decomposition and recomposition