On Tue, Oct 26, 2021 at 2:21 PM Thomas Munro wrote:
> Here's one like that. The previous message "Track LLVM 14 API
> changes" didn't seem too scalable so I added date and commit ID.
seawasp finally caught up with these LLVM changes and turned red. I
retested the patch against this week's LLVM
On Tue, Oct 26, 2021 at 1:52 PM Andres Freund wrote:
> On 2021-10-26 13:39:53 +1300, Thomas Munro wrote:
> > According to my crystal ball, seawasp will shortly break again[1][2]
> > and the attached patch will fix it.
>
> That feels lot more convincing though. Based on past experience it's not har
Hi,
On 2021-10-26 13:39:53 +1300, Thomas Munro wrote:
> On Mon, Sep 27, 2021 at 10:54 AM Thomas Munro wrote:
> > And pushed. Probably won't be the last change and seawasp only tests
> > master, so no back-patch for now.
>
> According to my crystal ball, seawasp will shortly break again[1][2]
>
On Mon, Sep 27, 2021 at 10:54 AM Thomas Munro wrote:
> And pushed. Probably won't be the last change and seawasp only tests
> master, so no back-patch for now.
According to my crystal ball, seawasp will shortly break again[1][2]
and the attached patch will fix it.
[1]
https://github.com/llvm/l
On Fri, Sep 24, 2021 at 12:52 PM Thomas Munro wrote:
> Yeah, that's already stopped working since you wrote it a few weeks
> ago... There's also been a second breakage site in our code due to
> LLVM commit 85b732b5. New fix attached. Tested on LLVM 7, 9, 13, 14
> (= LLVM main branch commit 945df
On Mon, Aug 30, 2021 at 5:41 AM Andres Freund wrote:
> - if (F.getAttributes().hasFnAttribute(llvm::Attribute::NoInline))
> + if (F.getAttributes().hasAttribute(llvm::Attribute::FunctionIndex,
> llvm::Attribute::NoInline))
Yeah, that's already stopped working since you wrote it a few
Hi,
On 2021-08-22 09:22:43 -0400, Tom Lane wrote:
> Seems like either we should push back on pointless renaming, or else
> that we're not really supposed to be accessing this non-stable API.
Unfortunately LLVM only considers the C API (and even there only subsets) as
stable. Most of our code uses
On 2021-Aug-29, Tom Lane wrote:
> I stand by my opinion that Thomas' patch is a kluge rather than something
> we should accept as a long-term answer. However, in the interests of
> keeping the buildfarm green, maybe we should commit it until we have a
> better solution. It looks like seawasp is
Alvaro Herrera writes:
> On 2021-Aug-22, Tom Lane wrote:
>> Thomas Munro writes:
>>> After [1], seawasp blew up[2]. I tested the following fix on LLVM 13
>>> and 14 (main branch ~2 days ago). Better ideas welcome.
>>>
>>> - if (F.getAttributes().hasFnAttribute(llvm::Attribute::NoInline))
On 2021-Aug-22, Tom Lane wrote:
> Thomas Munro writes:
> > After [1], seawasp blew up[2]. I tested the following fix on LLVM 13
> > and 14 (main branch ~2 days ago). Better ideas welcome.
>
> > - if (F.getAttributes().hasFnAttribute(llvm::Attribute::NoInline))
> > +#if LLVM_VERSION_MAJOR
Thomas Munro writes:
> After [1], seawasp blew up[2]. I tested the following fix on LLVM 13
> and 14 (main branch ~2 days ago). Better ideas welcome.
> - if (F.getAttributes().hasFnAttribute(llvm::Attribute::NoInline))
> +#if LLVM_VERSION_MAJOR < 14
> +#define hasFnAttr hasFnAttribute
> +
Hi,
After [1], seawasp blew up[2]. I tested the following fix on LLVM 13
and 14 (main branch ~2 days ago). Better ideas welcome.
- if (F.getAttributes().hasFnAttribute(llvm::Attribute::NoInline))
+#if LLVM_VERSION_MAJOR < 14
+#define hasFnAttr hasFnAttribute
+#endif
+
+ if (F.getAtt
12 matches
Mail list logo
