[Bug ada/109670] New: SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[Bug ada/109670] New: SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

            Bug ID: 109670
           Summary: SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES
                    compilation error on 32bit Windows starting with GCC
                    13
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
          Assignee: unassigned at gcc dot gnu.org
          Reporter: reiter.christoph at gmail dot com
                CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Updating from 12.2.0 to 13.1.0 we are encountering build errors for all ada
packages on 32bit Windows, all failing with something like:

raised SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES : s-pehage.adb:693
gnatmake: "broken.adb" compilation error

I've reduced one ada example that fails down to:

```
with GNAT.Spitbol.Patterns;
procedure Broken is
   M : GNAT.Spitbol.Patterns.Match_Result;
   type Header_Symbol is (None, Name, Attr, Conv, Prag);
begin
   null;
end Broken;
```

With GCC 12.2.0:

```
$ gnatmake.exe broken.adb
gcc -c broken.adb
gnatbind -x broken.ali
gnatlink broken.ali

```

With GCC 13.1.0:

```
$ gnatmake.exe broken.adb
gcc -c broken.adb

raised SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES : s-pehage.adb:693
gnatmake: "broken.adb" compilation error
```

If there is any more info that I can provide or things I can try out please let
me know.

[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #1 from Christoph Reiter <reiter.christoph at gmail dot com> ---
Could this be another case of exceptions being broken, as indicated here
https://github.com/AdaCore/gnat-llvm/issues/25#issuecomment-1057198363 ?
I see some "-static-libgcc" in the ada Makefile.in. I'll try building without
that.

[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #2 from Christoph Reiter <reiter.christoph at gmail dot com> ---
(In reply to Christoph Reiter from comment #1)
> [...] I'll try building without that.

That didn't make a difference sadly.

[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #3 from Christoph Reiter <reiter.christoph at gmail dot com> ---
This looks very much like bug 108202 though, so I'll see if I can find
something.

[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #4 from Christoph Reiter <reiter.christoph at gmail dot com> ---
Everything seems to be dynamically linked to libgcc, I'm out of ideas.

[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #5 from Christoph Reiter <reiter.christoph at gmail dot com> ---
Taking `libgcc_s_dw2-1.dll` from gcc 12.2 fixes the issue. We also found that
gdb and cmake are broken due to broken exception handling (in case of cmake it
is flaky). In both those cases taking the old `libgcc_s_dw2-1.dll` also helps.

So this is not ada specific, but exception handling being broken for 32bit
Windows.

[Bug libgcc/109670] Exception handling broken for 32bit Windows starting with GCC 13

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

LIU Hao <lh_mouse at 126 dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lh_mouse at 126 dot com

--- Comment #6 from LIU Hao <lh_mouse at 126 dot com> ---
Try reverting 1c118c9970600117700cc12284587e0238de6bbe?

[Bug libgcc/109670] Exception handling broken for 32bit Windows starting with GCC 13

[reiter.christoph at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

Christoph Reiter <reiter.christoph at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tneumann at users dot sourceforge.
                   |                            |net

--- Comment #7 from Christoph Reiter <reiter.christoph at gmail dot com> ---
Yes, I can confirm that reverting
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1c118c9970600117700cc12284587e0238de6bbe
on top of 13.1.0 fixes exception handling, and cmake/ada/gdb work again.

[Bug libgcc/109670] Exception handling broken for 32bit Windows starting with GCC 13

[tneumann at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #8 from Thomas Neumann <tneumann at users dot sourceforge.net> ---
Do you by chance an Ada-enabled WIN32 toolchain somewhere that I can use to
build gcc with? Or an script on how to do that? I have not managed to reproduce
the problem yet, unfortunately, because I could not build Ada.

[Bug libgcc/109670] Exception handling broken for 32bit Windows starting with GCC 13

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #9 from LIU Hao <lh_mouse at 126 dot com> ---
GDB is affected, too:

https://github.com/msys2/MINGW-packages/pull/16968#issuecomment-1533702758

[Bug libgcc/109670] Exception handling broken for 32bit Windows starting with GCC 13

[tneumann at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #10 from Thomas Neumann <tneumann at users dot sourceforge.net> ---
(In reply to LIU Hao from comment #9)
> GDB is affected, too:

I will debug that. That is easier to build than Ada. Strange that it only
affects 32bit Windows. I will take a look.

[Bug libgcc/109670] Exception handling broken for 32bit Windows starting with GCC 13

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #11 from LIU Hao <lh_mouse at 126 dot com> ---
(In reply to Thomas Neumann from comment #10)
> (In reply to LIU Hao from comment #9)
> > GDB is affected, too:
> 
> I will debug that. That is easier to build than Ada. Strange that it only
> affects 32bit Windows. I will take a look.

Only on i686-w64-mingw64 is DWARF2 used for exception handling; SEH is used on
all the other *-w64-mingw32 targets.

[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org
   Target Milestone|---                         |13.2
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-05-09
           Severity|normal                      |major
            Summary|Exception handling broken   |[13/14 regression]
                   |for 32bit Windows starting  |Exception handling broken
                   |with GCC 13                 |for 32-bit Windows

[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows

[tneumann at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #12 from Thomas Neumann <tneumann at users dot sourceforge.net> ---
Created attachment 55037
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55037&action=edit
radix sort fix

I could reproduce the problem, the radix sort did not behave correctly when we
ran out of bits, which can happen on 32bit platforms. The attached patch fixes
the problem.

[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #13 from LIU Hao <lh_mouse at 126 dot com> ---
I will test this later today.

[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #14 from LIU Hao <lh_mouse at 126 dot com> ---
(In reply to Thomas Neumann from comment #12)
> Created attachment 55037 [details]
> radix sort fix
> 
> I could reproduce the problem, the radix sort did not behave correctly when
> we ran out of bits, which can happen on 32bit platforms. The attached patch
> fixes the problem.

This fixes GDB for me.

[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows

[reiter.christoph at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #15 from Christoph Reiter <reiter.christoph at gmail dot com> ---
(In reply to Thomas Neumann from comment #12)
> Created attachment 55037 [details]
> radix sort fix
> 
> I could reproduce the problem, the radix sort did not behave correctly when
> we ran out of bits, which can happen on 32bit platforms. The attached patch
> fixes the problem.

I can confirm that this fixes the issue for me.

[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Neumann <tneumann@gcc.gnu.org>:

https://gcc.gnu.org/g:38e88d41f50d844f1404172657ef7e8372014ef6

commit r14-1515-g38e88d41f50d844f1404172657ef7e8372014ef6
Author: Thomas Neumann <tneumann@users.sourceforge.net>
Date:   Wed May 10 12:33:49 2023 +0200

    fix radix sort on 32bit platforms [PR109670]

    The radix sort uses two buffers, a1 for input and a2 for output.
    After every digit the role of the two buffers is swapped.
    When terminating the sort early the code made sure the output
    was in a2.  However, when we run out of bits, as can happen on
    32bit platforms, the sorted result was in a1, as we had just
    swapped a1 and a2.
    This patch fixes the problem by unconditionally having a1 as
    output after every loop iteration.

    This bug manifested itself only on 32bit platforms and even then
    only in some circumstances, as it needs frames where a swap
    is required due to differences in the top-most byte, which is
    affected by ASLR. The new logic was validated by exhaustive
    search over 32bit input values.

    libgcc/ChangeLog:
            PR libgcc/109670
            * unwind-dw2-fde.c: Fix radix sort buffer management.

[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Thomas Neumann
<tneumann@gcc.gnu.org>:

https://gcc.gnu.org/g:7b21a74b41b30cd070f69523edf9583d1e287249

commit r13-7411-g7b21a74b41b30cd070f69523edf9583d1e287249
Author: Thomas Neumann <tneumann@users.sourceforge.net>
Date:   Wed May 10 12:33:49 2023 +0200

    fix radix sort on 32bit platforms [PR109670]

    The radix sort uses two buffers, a1 for input and a2 for output.
    After every digit the role of the two buffers is swapped.
    When terminating the sort early the code made sure the output
    was in a2.  However, when we run out of bits, as can happen on
    32bit platforms, the sorted result was in a1, as we had just
    swapped a1 and a2.
    This patch fixes the problem by unconditionally having a1 as
    output after every loop iteration.

    This bug manifested itself only on 32bit platforms and even then
    only in some circumstances, as it needs frames where a swap
    is required due to differences in the top-most byte, which is
    affected by ASLR. The new logic was validated by exhaustive
    search over 32bit input values.

    libgcc/ChangeLog:
            PR libgcc/109670
            * unwind-dw2-fde.c: Fix radix sort buffer management.

[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

Mikael Pettersson <mikpelinux at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpelinux at gmail dot com

--- Comment #18 from Mikael Pettersson <mikpelinux at gmail dot com> ---
Since the fix has been backported to gcc-13 branch, can this be closed now?

[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows

[tneumann at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

--- Comment #19 from Thomas Neumann <tneumann at users dot sourceforge.net> ---
I think we can close this bug as fixed, but I do not have permissions to do
that.

[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #20 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Thomas Neumann from comment #19)
> I think we can close this bug as fixed, but I do not have permissions to do
> that.

Closing.