[Bug lto/106170] New: win32 thread model does not pthread.h. lto-plugin fails with canadian compilation

[Bug lto/106170] New: win32 thread model does not pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com]

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

            Bug ID: 106170
           Summary: win32 thread model does not pthread.h. lto-plugin
                    fails with canadian compilation
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: unlvsur at live dot com
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

make[4]: Entering directory
'/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/x86_64-w64-mingw32/gcc/gmp/demos'
Making all in calc
../../../../../gcc/lto-plugin/lto-plugin.c:62:10: fatal error: pthread.h: No
such file or directory
   62 | #include <pthread.h>
      |          ^~~~~~~~~~~

win32 thread model's gcc does not have pthread.h

[Bug lto/106170] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com]

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

--- Comment #1 from cqwrteur <unlvsur at live dot com> ---
windows does not provide those things. You can use EnterCriticalSection/
LeaveCriticalSection instead.

I can write a patch to fix it for windows.

[Bug lto/106170] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com]

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

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |unlvsur at live dot com

--- Comment #2 from cqwrteur <unlvsur at live dot com> ---
Created attachment 53242
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53242&action=edit
This patch just fixed the compilation part for windows. -pthread flag is a huge
issue

I do not know how to fix that.

[Bug lto/106170] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com]

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

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #53242|0                           |1
        is obsolete|                            |

--- Comment #3 from cqwrteur <unlvsur at live dot com> ---
Created attachment 53243
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53243&action=edit
Update patch

[Bug lto/106170] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com]

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

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #53243|0                           |1
        is obsolete|                            |

--- Comment #4 from cqwrteur <unlvsur at live dot com> ---
Created attachment 53244
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53244&action=edit
My patch without autoreconf. Please run autoreconf by yourself

I have just fixed them, but need to run autoreconf by yourself.

BTW. -lpthread -pthread lpthreads whatever i remember they all exist.

Plus win32 does not need -lpthread anymore since it uses win32 CriticalSection
api.

[Bug lto/106170] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com]

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

cqwrteur <unlvsur at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #53244|0                           |1
        is obsolete|                            |

--- Comment #5 from cqwrteur <unlvsur at live dot com> ---
Created attachment 53245
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53245&action=edit
Patch by manually copying autoconf. better use autoreconf

pthread_mutex_lock and pthread_mutex_unlock can fail. Better just let the
program crash if they fail.

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|x86_64-w64-mingw32 host GCC |[13 Regression]
                   |with win32 thread model     |x86_64-w64-mingw32 host GCC
                   |does not provide pthread.h. |with win32 thread model
                   |lto-plugin fails with       |does not provide pthread.h.
                   |canadian compilation        |lto-plugin fails with
                   |                            |canadian compilation
   Target Milestone|---                         |13.0
           Keywords|                            |build
           Priority|P3                          |P1

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Another possibility would be to white-list targets that should have a
thread-safe plugin.

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com]

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

--- Comment #7 from cqwrteur <unlvsur at live dot com> ---
(In reply to Richard Biener from comment #6)
> Another possibility would be to white-list targets that should have a
> thread-safe plugin.

std::atomic is freestanding. so technically adding a spin lock for an
unsupported target would be possible. However, it is still risky.

Whatever, for windows, I would suggest for using win32 CriticalSection api.

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-07-04
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |marxin at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
Mine.

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Liska <marxin@gcc.gnu.org>:

https://gcc.gnu.org/g:d89fa97ff318b1f892e2629c5a249313872a01b1

commit r13-1558-gd89fa97ff318b1f892e2629c5a249313872a01b1
Author: Martin Liska <mliska@suse.cz>
Date:   Thu Jul 7 12:15:28 2022 +0200

    lto-plugin: use locking only for selected targets

    For now, support locking only for linux targets that are different from
    riscv* where the target depends on libatomic (and fails during
    bootstrap).

            PR lto/106170

    lto-plugin/ChangeLog:

            * configure.ac: Configure HAVE_PTHREAD_LOCKING.
            * lto-plugin.c (LOCK_SECTION): New.
            (UNLOCK_SECTION): New.
            (claim_file_handler): Use the newly added macros.
            (onload): Likewise.
            * config.h.in: Regenerate.
            * configure: Regenerate.

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from Martin Liška <marxin at gcc dot gnu.org> ---
Should be fixed now.

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com]

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

--- Comment #11 from cqwrteur <unlvsur at live dot com> ---
(In reply to Martin Liška from comment #10)
> Should be fixed now.

So it does not matter not for adding locks for windows hosts? No need for using
CriticalSection APIs as locks?

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> ---
> So it does not matter not for adding locks for windows hosts? No need for
> using CriticalSection APIs as locks?

Well, we need the critical section for the multi-threaded linker mold for that
we define a new API. And the linker does not work on Windows, so we won't need
it.

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[pinskia at gcc dot gnu.org]

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

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #12)
> > So it does not matter not for adding locks for windows hosts? No need for
> > using CriticalSection APIs as locks?
> 
> Well, we need the critical section for the multi-threaded linker mold for
> that we define a new API. And the linker does not work on Windows, so we
> won't need it.

Even as cross to an elf target?

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com]

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

--- Comment #14 from cqwrteur <unlvsur at live dot com> ---
(In reply to Andrew Pinski from comment #13)
> (In reply to Martin Liška from comment #12)
> > > So it does not matter not for adding locks for windows hosts? No need for
> > > using CriticalSection APIs as locks?
> > 
> > Well, we need the critical section for the multi-threaded linker mold for
> > that we define a new API. And the linker does not work on Windows, so we
> > won't need it.
> 
> Even as cross to an elf target?

I actually do this. Cross compile x86_64-linux-gnu or aarch64-linux-gnu
programs on windows.

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|marxin at gcc dot gnu.org          |unassigned at gcc dot gnu.org
             Status|RESOLVED                    |NEW
         Resolution|FIXED                       |---

--- Comment #15 from Martin Liška <marxin at gcc dot gnu.org> ---
Feel free to provide Windows implementation of the critical section.

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com]

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

--- Comment #16 from cqwrteur <unlvsur at live dot com> ---
(In reply to Martin Liška from comment #15)
> Feel free to provide Windows implementation of the critical section.

make[4]: Leaving directory
'/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/loongarch64-linux-gnu/gcc/gmp/doc'
/home/cqwrteur/toolchains/native/x86_64-w64-mingw32/lib/gcc/x86_64-w64-mingw32/13.0.0/../../../../x86_64-w64-mingw32/bin/ld:
cannot find -lpthread: No such file or directory
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:472: liblto_plugin.la] Error 1
make[3]: Leaving directory
'/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/loongarch64-linux-gnu/gcc/lto-plugin'
make[2]: *** [Makefile:383: all] Error 2
make[2]: Leaving directory
'/home/cqwrteur/toolchains_build/gcc_build/x86_64-w64-mingw32/loongarch64-linux-gnu/gcc/lto-plugin'
make[1]: *** [Makefile:12790: all-lto-plugin] Error 2
make[1]: *** Waiting for unfinished jobs....

It still has not yet fixed

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[unlvsur at live dot com]

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

--- Comment #17 from cqwrteur <unlvsur at live dot com> ---
(In reply to Martin Liška from comment #15)
> Feel free to provide Windows implementation of the critical section.

case $target in
  riscv*)
    # do not use locking as pthread depends on libatomic
    ;;
  *-linux*)
    use_locking=yes
    ;;
esac


This should be $host, not $target

case $host in
  riscv*)
    # do not use locking as pthread depends on libatomic
    ;;
  *-linux*)
    use_locking=yes
    ;;
esac

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Liska <marxin@gcc.gnu.org>:

https://gcc.gnu.org/g:5d8637208d35f78b51f8cff38c984836ab2c860f

commit r13-1914-g5d8637208d35f78b51f8cff38c984836ab2c860f
Author: Martin Liska <mliska@suse.cz>
Date:   Mon Aug 1 10:32:00 2022 +0200

    lto: replace $target with $host in configure.ac [PR106170]

            PR lto/106170

    lto-plugin/ChangeLog:

            * configure.ac: Replace $target with $host.
            * configure: Regenerate.

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[marxin at gcc dot gnu.org]

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

--- Comment #19 from Martin Liška <marxin at gcc dot gnu.org> ---
Should be fixed now.

[Bug lto/106170] [13 Regression] x86_64-w64-mingw32 host GCC with win32 thread model does not provide pthread.h. lto-plugin fails with canadian compilation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
.