Обсуждение: Fix typo 586/686 in atomics/arch-x86.h
That's a typo in src/include/port/atomics/arch-x86.h, isn't it ?: if defined(__i568__) || defined(__i668__) || /* gcc i586+ */ If yes, then a patch is attached. Not that it harms something or somebody has such old hardware, but I've just spotted it while looking for something else. -J.
Вложения
> On 28 Nov 2025, at 09:44, Jakub Wartak <jakub.wartak@enterprisedb.com> wrote: > > That's a typo in src/include/port/atomics/arch-x86.h, isn't it ?: > if defined(__i568__) || defined(__i668__) || /* gcc i586+ */ > If yes, then a patch is attached. Not that it harms something or > somebody has such old hardware, but I've just spotted it while looking > for something else. That indeed looks like a clear typo, but if noone has complained since 2017 then maybe removing the checks is the right course of action? -- Daniel Gustafsson
On Fri, Nov 28, 2025 at 4:00 PM Daniel Gustafsson <daniel@yesql.se> wrote: > > > On 28 Nov 2025, at 09:44, Jakub Wartak <jakub.wartak@enterprisedb.com> wrote: > > > > That's a typo in src/include/port/atomics/arch-x86.h, isn't it ?: > > if defined(__i568__) || defined(__i668__) || /* gcc i586+ */ > > If yes, then a patch is attached. Not that it harms something or > > somebody has such old hardware, but I've just spotted it while looking > > for something else. > > That indeed looks like a clear typo, but if noone has complained since 2017 > then maybe removing the checks is the right course of action? I believe CI tests with -m32, so as long as we do that we should probably make that work the way we think it does. -- John Naylor Amazon Web Services
> On 19 Dec 2025, at 08:23, John Naylor <johncnaylorls@gmail.com> wrote: > > On Fri, Nov 28, 2025 at 4:00 PM Daniel Gustafsson <daniel@yesql.se> wrote: >> >>> On 28 Nov 2025, at 09:44, Jakub Wartak <jakub.wartak@enterprisedb.com> wrote: >>> >>> That's a typo in src/include/port/atomics/arch-x86.h, isn't it ?: >>> if defined(__i568__) || defined(__i668__) || /* gcc i586+ */ >>> If yes, then a patch is attached. Not that it harms something or >>> somebody has such old hardware, but I've just spotted it while looking >>> for something else. >> >> That indeed looks like a clear typo, but if noone has complained since 2017 >> then maybe removing the checks is the right course of action? > > I believe CI tests with -m32, so as long as we do that we should > probably make that work the way we think it does. It does, but will this affect that? Does gcc change the CPU arch to 32bit era hardware when using -m32? I was under the impression that it built code that can run in 32-bit mode on the underlying hardware unless a specific target arch was defined - but this is outside my wheelhouse so I might well be uninformed. Regardless, applying this shouldn't affect anything unless compiling on Pentium Pro or pre-MMX Pentium instruction sets, so it seems quite harmless and as the intention was to support it the best course of action is probably to just apply this. -- Daniel Gustafsson
> It does, but will this affect that? Does gcc change the CPU arch to 32bit era > hardware when using -m32? I did some quick testing with this, normally only __i386__ gets defined for 32 bit builds (-march=native -m32 for example, but also the default -march=x86-64 -m32). __i586__ and __i686__ are only there if I pass the matching -march (i586/i686) flag to gcc.
On Fri, Dec 19, 2025 at 5:13 PM Zsolt Parragi <zsolt.parragi@percona.com> wrote: > I did some quick testing with this, normally only __i386__ gets > defined for 32 bit builds (-march=native -m32 for example, but also > the default -march=x86-64 -m32). __i586__ and __i686__ are only there > if I pass the matching -march (i586/i686) flag to gcc. What platform is this? I don't see that: gcc 14: $ echo | gcc -m32 -dM -E - | grep -E '86[^0-9]' #define __i686 1 #define __i686__ 1 #define __i386 1 #define i386 1 #define __i386__ 1 clang 19: $ echo | clang -m32 -dM -E - | grep -E '86[^0-9]' #define __i386 1 #define __i386__ 1 #define i386 1 -- John Naylor Amazon Web Services
John Naylor <johncnaylorls@gmail.com> writes:
> On Fri, Dec 19, 2025 at 5:13 PM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
>> I did some quick testing with this, normally only __i386__ gets
>> defined for 32 bit builds (-march=native -m32 for example, but also
>> the default -march=x86-64 -m32). __i586__ and __i686__ are only there
>> if I pass the matching -march (i586/i686) flag to gcc.
> What platform is this? I don't see that:
I can replicate Zsolt's result --- note the point about -march:
$ echo | gcc -m32 -dM -E - | grep -E '86[^0-9]'
#define __i386 1
#define __i386__ 1
#define i386 1
$ echo | gcc -m32 -march=i586 -dM -E - | grep -E '86[^0-9]'
#define __i586 1
#define __tune_i586__ 1
#define __i386 1
#define __i586__ 1
#define __i386__ 1
#define i386 1
$ echo | gcc -m32 -march=i686 -dM -E - | grep -E '86[^0-9]'
#define __tune_i686__ 1
#define __i686 1
#define __i686__ 1
#define __i386 1
#define __i386__ 1
#define i386 1
This is with gcc 8.5.0 from RHEL8, and the same with gcc 14.3.1
from Fedora 41.
regards, tom lane
On Sat, Dec 20, 2025 at 9:01 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > John Naylor <johncnaylorls@gmail.com> writes: > > On Fri, Dec 19, 2025 at 5:13 PM Zsolt Parragi <zsolt.parragi@percona.com> wrote: > >> I did some quick testing with this, normally only __i386__ gets > >> defined for 32 bit builds (-march=native -m32 for example, but also > >> the default -march=x86-64 -m32). __i586__ and __i686__ are only there > >> if I pass the matching -march (i586/i686) flag to gcc. > > > What platform is this? I don't see that: > > I can replicate Zsolt's result --- note the point about -march: > > $ echo | gcc -m32 -dM -E - | grep -E '86[^0-9]' > #define __i386 1 > #define __i386__ 1 > #define i386 1 > $ echo | gcc -m32 -march=i586 -dM -E - | grep -E '86[^0-9]' > #define __i586 1 > #define __tune_i586__ 1 > #define __i386 1 > #define __i586__ 1 > #define __i386__ 1 > #define i386 1 > $ echo | gcc -m32 -march=i686 -dM -E - | grep -E '86[^0-9]' > #define __tune_i686__ 1 > #define __i686 1 > #define __i686__ 1 > #define __i386 1 > #define __i386__ 1 > #define i386 1 > > This is with gcc 8.5.0 from RHEL8, and the same with gcc 14.3.1 > from Fedora 41. My results were from Fedora 41 gcc 14.3.1 as well. With '-march' I get the same as your 8.5.0 but in a slightly different order, but without it I still get some 'i686' symbols defined. -- John Naylor Amazon Web Services
On Fri, Dec 19, 2025 at 4:04 PM Daniel Gustafsson <daniel@yesql.se> wrote:
> > I believe CI tests with -m32, so as long as we do that we should
> > probably make that work the way we think it does.
>
> It does, but will this affect that? Does gcc change the CPU arch to 32bit era
> hardware when using -m32? I was under the impression that it built code that
> can run in 32-bit mode on the underlying hardware unless a specific target arch
> was defined - but this is outside my wheelhouse so I might well be uninformed.
It's outside mine as well, but when I saw this thread I thought of
Thomas's experiment to use <stdatomic.h> and the need to verify code
generation on various platforms, so I see this patch as preventing
some head-scratching with that effort. With this patch applied on a
non-debug -m32 build I do see changes with bloaty:
FILE SIZE VM SIZE
-------------- --------------
+0.3% +6.27Ki +0.3% +6.27Ki .eh_frame
-0.0% -16 -0.0% -16 .eh_frame_hdr
-0.0% -32 [ = ] 0 .symtab
-0.0% -47 [ = ] 0 .strtab
-0.0% -198 [ = ] 0 .debug_abbrev
-0.1% -512 [ = ] 0 .debug_rnglists
-34.3% -3.20Ki [ = ] 0 [Unmapped]
-0.1% -3.63Ki [ = ] 0 .debug_line
-0.1% -7.06Ki -0.1% -7.06Ki .text
-0.2% -8.44Ki [ = ] 0 .debug_loclists
-0.0% -8.70Ki [ = ] 0 .debug_info
-0.1% -25.5Ki -0.0% -824 TOTAL
--
John Naylor
Amazon Web Services
It seems this is dependent on the linux distribution. I assumed gcc uses the same march on all modern linux distributions, but that doesn't seem to be the case. OL 8/9/10, Gentoo, Arch seem to keep the x86-64 march even when you specify -m32: bash-5.2# gcc -m32 -Q --help=target | grep march -march= x86-64 Known valid arguments for -march= option: bash-5.2# gcc -Q --help=target | grep march -march= x86-64-v3 Known valid arguments for -march= option: But Ubuntu/Debian changes march to i386 when you do that: ❯ gcc -m32 -Q --help=target | grep march -march= i686 Known valid arguments for -march= option: ❯ gcc -Q --help=target | grep march -march= x86-64 Known valid arguments for -march= option: Gcc version doesn't seem to change this even if I install multiple gcc versions on the same setup.
Zsolt Parragi <zsolt.parragi@percona.com> writes:
> It seems this is dependent on the linux distribution. I assumed gcc
> uses the same march on all modern linux distributions, but that
> doesn't seem to be the case.
It may be changing with time, too. Same experiment on Red Hat distros:
gcc 8.5.0 on RHEL8:
$ gcc -Q --help=target | grep march
-march= x86-64
$ gcc -m32 -Q --help=target | grep march
-march= x86-64
gcc 11.5.0 on RHEL9:
$ gcc -Q --help=target | grep march
-march= x86-64-v2
Known valid arguments for -march= option:
$ gcc -m32 -Q --help=target | grep march
-march= x86-64
Known valid arguments for -march= option:
gcc 14.3.1 on Fedora 41:
$ gcc -Q --help=target | grep march
-march= x86-64
Known valid arguments for -march= option:
$ gcc -m32 -Q --help=target | grep march
-march= i686
Known valid arguments for -march= option:
regards, tom lane