Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Remove support for 8 byte tear free read/write on 32-bit

  1. Fix typo 586/686 in atomics/arch-x86.h

    Jakub Wartak <jakub.wartak@enterprisedb.com> — 2025-11-28T08:44:37Z

    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.

  2. Re: Fix typo 586/686 in atomics/arch-x86.h

    Daniel Gustafsson <daniel@yesql.se> — 2025-11-28T09:00:21Z

    > 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

  3. Re: Fix typo 586/686 in atomics/arch-x86.h

    John Naylor <johncnaylorls@gmail.com> — 2025-12-19T07:23:31Z

    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

  4. Re: Fix typo 586/686 in atomics/arch-x86.h

    Daniel Gustafsson <daniel@yesql.se> — 2025-12-19T09:04:40Z

    > 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

  5. Re: Fix typo 586/686 in atomics/arch-x86.h

    Zsolt Parragi <zsolt.parragi@percona.com> — 2025-12-19T10:13:32Z

    > 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.

  6. Re: Fix typo 586/686 in atomics/arch-x86.h

    John Naylor <johncnaylorls@gmail.com> — 2025-12-20T01:37:35Z

    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

  7. Re: Fix typo 586/686 in atomics/arch-x86.h

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-12-20T02:01:23Z

    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

  8. Re: Fix typo 586/686 in atomics/arch-x86.h

    John Naylor <johncnaylorls@gmail.com> — 2025-12-20T02:30:37Z

    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

  9. Re: Fix typo 586/686 in atomics/arch-x86.h

    John Naylor <johncnaylorls@gmail.com> — 2025-12-20T02:37:14Z

    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

  10. Re: Fix typo 586/686 in atomics/arch-x86.h

    Zsolt Parragi <zsolt.parragi@percona.com> — 2025-12-20T07:38:59Z

    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.

  11. Re: Fix typo 586/686 in atomics/arch-x86.h

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-12-20T21:31:13Z

    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

  12. Re: Fix typo 586/686 in atomics/arch-x86.h

    Daniel Gustafsson <daniel@yesql.se> — 2026-05-07T20:59:26Z

    > On 11 Mar 2026, at 16:51, Andres Freund <andres@anarazel.de> wrote:

> I do think we should drop the 32bit support, rather than fixing the typos.

Attached is a patch against HEAD for this.  Reading your mail my interpretation
was that this was equally broken for MSVC even though the macro is correct
there, and we should remove both.  Was that a correct reading?

I'm not sure it's worth doing this to the backbranches, seems like we can keep
this a v19+ fix.

--
Daniel Gustafsson

  13. Re: Fix typo 586/686 in atomics/arch-x86.h

    Nathan Bossart <nathandbossart@gmail.com> — 2026-05-07T21:44:45Z

    On Thu, May 07, 2026 at 10:59:26PM +0200, Daniel Gustafsson wrote:
> Attached is a patch against HEAD for this.  Reading your mail my interpretation
> was that this was equally broken for MSVC even though the macro is correct
> there, and we should remove both.  Was that a correct reading?

Yeah, atomics.h doesn't use the right macro for MSVC, so nothing in this
file is compiled for MSVC anyway.  However, I suspect the proper fix is to
make sure this file is included for MSVC.  Note that the other MSVC code in
this file is similarly broken, but fortunately isn't used anywhere [0].

> I'm not sure it's worth doing this to the backbranches, seems like we can keep
> this a v19+ fix.

+1

[0] https://postgr.es/m/afouZUH_eUkIj4i4%40nathan

-- 
nathan

  14. Re: Fix typo 586/686 in atomics/arch-x86.h

    Nathan Bossart <nathandbossart@gmail.com> — 2026-05-07T21:46:08Z

    On Thu, May 07, 2026 at 04:44:45PM -0500, Nathan Bossart wrote:
> On Thu, May 07, 2026 at 10:59:26PM +0200, Daniel Gustafsson wrote:
>> Attached is a patch against HEAD for this.  Reading your mail my interpretation
>> was that this was equally broken for MSVC even though the macro is correct
>> there, and we should remove both.  Was that a correct reading?
> 
> Yeah, atomics.h doesn't use the right macro for MSVC, so nothing in this
> file is compiled for MSVC anyway.  However, I suspect the proper fix is to
> make sure this file is included for MSVC.  Note that the other MSVC code in
> this file is similarly broken, but fortunately isn't used anywhere [0].

To be clear, I'm +1 on removing any 32-bit code in this file.  But the
64-bit stuff should probably be fixed.

-- 
nathan

  15. Re: Fix typo 586/686 in atomics/arch-x86.h

    Daniel Gustafsson <daniel@yesql.se> — 2026-05-08T07:32:16Z

    > On 7 May 2026, at 23:46, Nathan Bossart <nathandbossart@gmail.com> wrote:
> 
> On Thu, May 07, 2026 at 04:44:45PM -0500, Nathan Bossart wrote:
>> On Thu, May 07, 2026 at 10:59:26PM +0200, Daniel Gustafsson wrote:
>>> Attached is a patch against HEAD for this.  Reading your mail my interpretation
>>> was that this was equally broken for MSVC even though the macro is correct
>>> there, and we should remove both.  Was that a correct reading?
>> 
>> Yeah, atomics.h doesn't use the right macro for MSVC, so nothing in this
>> file is compiled for MSVC anyway.  However, I suspect the proper fix is to
>> make sure this file is included for MSVC.  Note that the other MSVC code in
>> this file is similarly broken, but fortunately isn't used anywhere [0].
> 
> To be clear, I'm +1 on removing any 32-bit code in this file.  But the
> 64-bit stuff should probably be fixed.

Agreed.  Reading over the threads you linked it seems the way forward is to
apply the patch posted here, and then fix arch detection so that atomics.h
picks up the right code for x86-64.

--
Daniel Gustafsson

  16. Re: Fix typo 586/686 in atomics/arch-x86.h

    Nathan Bossart <nathandbossart@gmail.com> — 2026-05-08T14:31:17Z

    On Fri, May 08, 2026 at 09:32:16AM +0200, Daniel Gustafsson wrote:
> On 7 May 2026, at 23:46, Nathan Bossart <nathandbossart@gmail.com> wrote:
>> To be clear, I'm +1 on removing any 32-bit code in this file.  But the
>> 64-bit stuff should probably be fixed.
> 
> Agreed.  Reading over the threads you linked it seems the way forward is to
> apply the patch posted here, and then fix arch detection so that atomics.h
> picks up the right code for x86-64.

+1

-- 
nathan

  17. Re: Fix typo 586/686 in atomics/arch-x86.h

    Daniel Gustafsson <daniel@yesql.se> — 2026-05-18T16:17:22Z

    > On 8 May 2026, at 07:31, Nathan Bossart <nathandbossart@gmail.com> wrote:
> 
> On Fri, May 08, 2026 at 09:32:16AM +0200, Daniel Gustafsson wrote:
>> On 7 May 2026, at 23:46, Nathan Bossart <nathandbossart@gmail.com> wrote:
>>> To be clear, I'm +1 on removing any 32-bit code in this file.  But the
>>> 64-bit stuff should probably be fixed.
>> 
>> Agreed.  Reading over the threads you linked it seems the way forward is to
>> apply the patch posted here, and then fix arch detection so that atomics.h
>> picks up the right code for x86-64.
> 
> +1

Done.

--
Daniel Gustafsson