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
On Sat, Jun 19, 2021 at 9:46 AM Tom Lane wrote:
> Fabien COELHO writes:
> >> It'd sure be nice if seawasp stopped spamming the buildfarm failure log,
> >> too.
>
> > There was a silent API breakage (same API, different behavior, how nice…)
> > in llvm main that Andres figured out, which will have
Hello Tom,
Could you please just shut down the animal until that's dealt with?
The test is failing because there is a problem, and shuting down the test
to improve a report does not in any way help to fix it, it just helps to
hide it.
Our buildfarm is run for the use of the Postgres projec
Fabien COELHO writes:
>> Could you please just shut down the animal until that's dealt with?
> The test is failing because there is a problem, and shuting down the test
> to improve a report does not in any way help to fix it, it just helps to
> hide it.
Our buildfarm is run for the use of the
Hello Tom,
So I'm not very confident that the noise will go away quickly, sorry.
Could you please just shut down the animal until that's dealt with?
Hmmm… Obviously I can.
However, please note that the underlying logic of "a test is failing,
let's just remove it" does not sound right to m
Fabien COELHO writes:
>> It'd sure be nice if seawasp stopped spamming the buildfarm failure log,
>> too.
> 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
It'd sure be nice if seawasp stopped spamming the buildfarm failure log,
too.
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… Not sure when
Alvaro Herrera writes:
> Hello, this problem is still happening; serinus' configure output says
> it's running a snapshot from 20210527, and Fabien mentioned downthread
> that his compiler stopped complaining on 2021-06-05. Andres, maybe the
> compiler in serinus is due for an update too?
Yeah,
On 2021-Jun-03, Michael Paquier wrote:
> Hi all,
>
> serinus has been complaining about the new gcd functions in 13~:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&dt=2021-06-03%2003%3A44%3A14
Hello, this problem is still happening; serinus' configure output says
it's running
serinus has been complaining about the new gcd functions in 13~:
moonjelly, which also runs a bleeding-edge gcc, started to fail the same
way at about the same time. Given that none of our code in that area
has changed, it's hard to think it's anything but a broken compiler.
Maybe somebod
serinus has been complaining about the new gcd functions in 13~:
moonjelly, which also runs a bleeding-edge gcc, started to fail the same
way at about the same time. Given that none of our code in that area
has changed, it's hard to think it's anything but a broken compiler.
Maybe somebod
Michael Paquier writes:
> serinus has been complaining about the new gcd functions in 13~:
moonjelly, which also runs a bleeding-edge gcc, started to fail the same
way at about the same time. Given that none of our code in that area
has changed, it's hard to think it's anything but a broken comp
Hello
I build gcc version 12.0.0 20210603 (experimental) locally, then tried
REL_13_STABLE with same CFLAGS as serinus
./configure --prefix=/home/melkij/tmp/pgdev/inst CFLAGS="-O3 -ggdb -g3 -Wall
-Wextra -Wno-unused-parameter -Wno-sign-compare
-Wno-missing-field-initializers" --enable-tap-tests
On Thu, 3 Jun 2021 at 08:26, Michael Paquier wrote:
>
> Hi all,
>
> serinus has been complaining about the new gcd functions in 13~:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&dt=2021-06-03%2003%3A44%3A14
>
> The overflow detection is going wrong the way up and down, like he
Hi all,
serinus has been complaining about the new gcd functions in 13~:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&dt=2021-06-03%2003%3A44%3A14
The overflow detection is going wrong the way up and down, like here:
SELECT gcd((-9223372036854775808)::int8, (-92233720368547758
15 matches
Mail list logo
