From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Subject: | Re: Failures with gcd functions with GCC snapshots GCC and -O3 (?) |
Date: | 2021-06-19 04:55:41 |
Message-ID: | alpine.DEB.2.22.394.2106190651240.3211875@pseudo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>> There was a silent API breakage (same API, different behavior, how nice…)
>>> in llvm main that Andres figured out, which will have to be fixed at some
>>> point, so this is reminder that it is still a todo…
>>
>> If it were *our* todo, that would be one thing; but it isn't.
>
> Over on the other thread[1] we learned that this is an API change
> affecting reference counting semantics[2], so unless there is some
> discussion somewhere about reverting the LLVM change that I'm unaware
> of, I'm guessing we're going to need to change our code sooner or
> later.
Indeed, I'm afraid the solution will have to be on pg side.
> I have a bleeding edge LLVM on my dev machine, and I'm willing to try to
> reproduce the crash and write the trivial patch (that is, figure out the
> right preprocessor incantation to detect the version or feature, and
> bump the reference count as appropriate), if Andres and/or Fabien aren't
> already on the case.
I'm not in the case, I'm only the one running the farm animal which barks
too annoyingly for Tom.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2021-06-19 05:07:51 | Re: seawasp failing, maybe in glibc allocator |
Previous Message | Julien Rouhaud | 2021-06-19 04:49:07 | Re: Centralizing protective copying of utility statements |