Thread: test failure with gcc-12 -O3 -march=native
Hi, For my optimized builds I've long used -O3 -march=native. After one of the recent package updates (I'm not certain when exactly yet), the main regression tests started to fail for me with that. Oddly enough in opr_sanity: -- Ask access methods to validate opclasses -- (this replaces a lot of SQL-level checks that used to be done in this file) SELECT oid, opcname FROM pg_opclass WHERE NOT amvalidate(oid); - oid | opcname ------+--------- -(0 rows) +INFO: operator family "array_ops" of access method hash contains function hash_array_extended(anyarray,bigint) with wrongsignature for support number 2 +INFO: operator family "bpchar_ops" of access method hash contains function hashbpcharextended(character,bigint) with wrongsignature for support number 2 ... + 16492 | part_test_int4_ops + 16497 | part_test_text_ops +(43 rows) Given that I did not encounter this problem with gcc-12 before, and that gcc-12 has been released, it seems less likely to be a bug in our code highlighted by a new optimization and more likely to be a bug in a gcc bugfix, but it's definitely not clear. I only investigated this a tiny bit so far. What fails is the procform->prorettype != restype comparison in check_hash_func_signature(). Greetings, Andres Freund
On Thu, Aug 11, 2022 at 01:03:43PM -0700, Andres Freund wrote: > Hi, > > For my optimized builds I've long used -O3 -march=native. After one of the On what kind of arch ? > Given that I did not encounter this problem with gcc-12 before, and that > gcc-12 has been released, it seems less likely to be a bug in our code > highlighted by a new optimization and more likely to be a bug in a gcc bugfix, > but it's definitely not clear. debian testing is now defaulting to gcc-12. https://tracker.debian.org/news/1348007/accepted-gcc-defaults-1198-source-into-unstable/ Are you sure you were building with gcc-12 and not gcc(default) which, until 3 weeks ago, was gcc-11 ? -- Justin
Hi, On 2022-08-11 20:06:02 -0500, Justin Pryzby wrote: > On Thu, Aug 11, 2022 at 01:03:43PM -0700, Andres Freund wrote: > > Hi, > > > > For my optimized builds I've long used -O3 -march=native. After one of the > > On what kind of arch ? x86-64 cascadelake. I've since debugged this further. It's not even -march that's the problem, it's the difference between -mtune=broadwell and -mtune=skylake, even with -march=x86-64. > > Given that I did not encounter this problem with gcc-12 before, and that > > gcc-12 has been released, it seems less likely to be a bug in our code > > highlighted by a new optimization and more likely to be a bug in a gcc bugfix, > > but it's definitely not clear. > > debian testing is now defaulting to gcc-12. > https://tracker.debian.org/news/1348007/accepted-gcc-defaults-1198-source-into-unstable/ > > Are you sure you were building with gcc-12 and not gcc(default) which, until 3 > weeks ago, was gcc-11 ? Yes. I'm now bisecting... Greetings, Andres Freund
Hi, On 2022-08-11 18:24:16 -0700, Andres Freund wrote: > > > Given that I did not encounter this problem with gcc-12 before, and that > > > gcc-12 has been released, it seems less likely to be a bug in our code > > > highlighted by a new optimization and more likely to be a bug in a gcc bugfix, > > > but it's definitely not clear. > > > > debian testing is now defaulting to gcc-12. > > https://tracker.debian.org/news/1348007/accepted-gcc-defaults-1198-source-into-unstable/ > > > > Are you sure you were building with gcc-12 and not gcc(default) which, until 3 > > weeks ago, was gcc-11 ? > > Yes. > > I'm now bisecting... I found the commit triggering it [1]. Oddly it's a change from a few months ago, and I can reconstruct from dpkg.log and shell history that I definitely ran the tests many times since upgrading the compiler. I did however clean my ccache cache yesterday, I wonder if somehow the 'old' version got stuck in it. ccache says it checks the compiler's mtime though. Greetings, Andres Freund [1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1ceddd7497e
Hi, On 2022-08-11 19:08:14 -0700, Andres Freund wrote: > On 2022-08-11 18:24:16 -0700, Andres Freund wrote: > > I'm now bisecting... > > I found the commit triggering it [1]. Oddly it's a change from a few months > ago, and I can reconstruct from dpkg.log and shell history that I definitely > ran the tests many times since upgrading the compiler. I did however clean my > ccache cache yesterday, I wonder if somehow the 'old' version got stuck in > it. ccache says it checks the compiler's mtime though. Spent a fair bit of time reducing the problem to something triggering the problem in isolation. This is somewhat scary - I'd be quite surprised if this were the only place triggering the bug. And I suspect that it doesn't actually require -mtune=skylake, but I'm not sure. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106590 Greetings, Andres Freund