Noah Misch <n...@leadboat.com> writes:
> On Mon, Oct 16, 2023 at 01:54:23AM -0400, Tom Lane wrote:
>> Ugh. So if the failure is robust enough to persist across
>> several major xlc versions, why couldn't Thomas reproduce it?
> Beats me. hornet wipes its starting environment down to OBJECT_MODE=32_64
> PERL5LIB=/home/nm/sw/cpan64/lib/perl5 SPECIES=xlc64 PATH=/usr/bin, then
> applies all the environment settings seen in buildfarm logs.
I was able to reproduce the failure on cfarm111 after adopting
these settings from hornet's configuration:
export OBJECT_MODE=64
export CC='xlc_r -D_LARGE_FILES=1 '
export CFLAGS='-O2 -qmaxmem=33554432 -qsuppress=1500-010:1506-995
-qsuppress=1506-010:1506-416:1506-450:1506-480:1506-481:1506-492:1506-944:1506-1264
-qinfo=all:nocnd:noeff:noext:nogot:noini:noord:nopar:noppc:norea:nouni:nouse
-qsuppress=1506-374:1506-419:1506-434:1506-438:1506-451:1506-452:1506-453:1506-495:1506-786'
and doing
./configure --enable-cassert --enable-debug --without-icu
--prefix=/home/tgl/testversion
etc etc.
It is absolutely, gold-platedly, a compiler bug, because inserting
a debug printf into the loop
while (result->time >= USECS_PER_DAY)
result->time -= USECS_PER_DAY;
makes the failure go away. Unfortunately, I've not yet found another
way to make it go away :-(. My upthread idea of using a local variable
instead of result->time is no help, and some other random code
alterations didn't change the results either.
Not sure where we go from here. While I don't have much hesitation
about blowing off xlc_r 12.1, it would be sad if their latest
toolchain doesn't work either. (I didn't try permuting the code
while using the newer compiler, though.)
regards, tom lane
