On Thu, Dec 14, 2017 at 6:37 AM, Andres Freund <andres@anarazel.de> wrote:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dangomushi&dt=2017-12-13%2018%3A00%3A18
>
> which seems half like a compiler bug to me. But either way, we gotta
> work around it. I suspect the reason configure test doesn't
> sufficiently detect this here is because it's testing the function with
> constant arguments.
This uses clang 5.0 and I can reproduce the failure manually:
$ clang --version
clang version 5.0.0 (tags/RELEASE_500/final)
Target: armv7l-unknown-linux-gnueabihf
Thread model: posix
InstalledDir: /usr/bin
Note that on the same machine using gcc 7.2.0 I am seeing no
compilation failures. ArchLinux maintainers can be sometimes wild in
the versions they push, I have seen that in the past. And Arch ARM has
less resources I think.
Also, gull is complaining with the same failure:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gull&dt=2017-12-13%2004%3A20%3A18
ARMv7 is used there as well, with clang 3.8, so this combination is deadly.
> Could you perhaps test whether replacing PGAC_C_BUILTIN_OP_OVERFLOW's body with something like
> result
> PG_INT64_TYPE a;
> PG_INT64_TYPE b;
> PG_INT64_TYPE result;
> __builtin_mul_overflow(*(volatile PG_INT64_TYPE*) &a, *(volatile PG_INT64_TYPE*) &b, &result);
>
> makes it fail? I'd rather not test this via the buildfarm, given that
> dangomushi isn't the most frequently running / fastest animal.
The tests are run once per day to not push too much its SD card.
Let me see... If I enforce also a cast on "result" as well then I am
able to compile correctly, which gives me the attached. make check
also works, I haven't taken the time to do a complete test run though,
this would take way longer on dangomushi.
--
Michael