[Bug c++/100160] New: MinGW-w64 g++ with libgomp and nvptx looks for libgomp-plugin-nvptx.so.1 instead of libgomp-plugin-nvptx-1.dll

[Bug c++/100160] New: MinGW-w64 g++ with libgomp and nvptx looks for libgomp-plugin-nvptx.so.1 instead of libgomp-plugin-nvptx-1.dll

[brechtsanders at users dot sourceforge.net]

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

            Bug ID: 100160
           Summary: MinGW-w64 g++ with libgomp and nvptx looks for
                    libgomp-plugin-nvptx.so.1 instead of
                    libgomp-plugin-nvptx-1.dll
           Product: gcc
           Version: 10.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: brechtsanders at users dot sourceforge.net
  Target Milestone: ---

Created attachment 50640
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50640&action=edit
Test source code to reproduce issue

(see issue reported here:
https://github.com/brechtsanders/winlibs_mingw/issues/51)

Several issues when using GCC built against MinGW-w64 for Windows to compile
gomp test code (see attached minimal source code).

Code compiles fine with:
g++ -c -o test.o test.cpp -fopenmp -foffload=nvptx-none

Linking fails when done like this:
g++ -o test.exe test.o -lgomp
mkoffload: fatal error: either '-fopenacc' or '-fopenmp' must be set
compilation terminated.
lto-wrapper.exe: fatal error:
d:/prog/winlibs64-10.3.0/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0//accel/nvptx-none/mkoffload.exe
returned 1 exit status
compilation terminated.
d:/prog/winlibs64-10.3.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status

Avoiding LTO seems to work around this and the following links fine:
g++ -o test.exe test.o -fno-lto -lgomp

When executing test.exe the output starts with:
libgomp: while loading libgomp-plugin-nvptx.so.1: "libgomp-plugin-nvptx.so.1":
The specified module could not be found.

The correct file on Windows is libgomp-plugin-nvptx-1.dll, not
libgomp-plugin-nvptx.so.1

After that the application runs, but I assume without gomp optimizations.

The g++ used in my case is the one I built myself from source, including nvptx
offload engine (can be downloaded from http://winlibs.com/):
g++ --version
g++.exe (MinGW-W64 x86_64-posix-seh, built by Brecht Sanders) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug libgomp/100160] MinGW-w64 g++ with libgomp and nvptx looks for libgomp-plugin-nvptx.so.1 instead of libgomp-plugin-nvptx-1.dll

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vries at gcc dot gnu.org

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Test-case updated: removed commented out lines, formatted, printing
omp_get_thread_num to get some printout that is not all zeroes:
...
#include <iostream>
#include <omp.h>

using namespace std;

int threads = omp_get_max_threads ();
int devices = omp_get_num_devices ();
int i, j[100];

int
main (void)
{
  printf ("Threads: %d Devices: %d\n", threads, devices);

#pragma omp target teams distribute parallel for shared(j)
  for(i = 0; i < 100; i++)
    j[i] = omp_get_thread_num ();

  for (i = 0; i < 100; i++)
    printf ("%d ", j[i]);

  return 0;
}
...

On ubuntu, we have:
...
$ ./install/bin/g++ test-1.cpp -fopenmp -foffload=nvptx-none -fno-lto
$ LD_LIBRARY_PATH=./install/lib64 ./a.out
Threads: 8 Devices: 1
0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 3
3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 5 5 6 6 6 6
6 6 6 6 6 6 6 6 7 7 7 7 7 7 7 7 7 7 7 7 
$
...

And:
...
$ ./install/bin/g++ test-1.cpp -fopenmp -foffload=nvptx-none 
lto-wrapper: fatal error: could not find accel/nvptx-none/mkoffload in
/home/vries/oacc/trunk/install/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/:/home/vries/oacc/trunk/install/bin/../libexec/gcc/
(consider using ‘-B’)
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
...

So, there might be something windows-specific that is going wrong.

But things seems to already go wrong on linux.

[Bug libgomp/100160] MinGW-w64 g++ with libgomp and nvptx looks for libgomp-plugin-nvptx.so.1 instead of libgomp-plugin-nvptx-1.dll

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #1)
> ...
> $ ./install/bin/g++ test-1.cpp -fopenmp -foffload=nvptx-none 
> lto-wrapper: fatal error: could not find accel/nvptx-none/mkoffload in
> /home/vries/oacc/trunk/install/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/
> :/home/vries/oacc/trunk/install/bin/../libexec/gcc/ (consider using ‘-B’)
> compilation terminated.
> /usr/bin/ld: error: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> ...

I can make this work by adding:
...
$ ./install/bin/g++ test-1.cpp -fopenmp -foffload=nvptx-none -flto \
  -B $(pwd
-P)/install/offload-nvptx-none/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/ \
  -B $(pwd -P)/install/offload-nvptx-none/bin/
$ LD_LIBRARY_PATH=./install/lib64 ./a.out
Threads: 8 Devices: 1
0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4
0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4 0 1 2 3 4
0 1 2 3 4 0 1 2 3 4 0 1 2 3 
...
Hmm, this actually executes on the target, the -fno-lto case executes the host
fallback.

[Bug libgomp/100160] MinGW-w64 g++ with libgomp and nvptx looks for libgomp-plugin-nvptx.so.1 instead of libgomp-plugin-nvptx-1.dll

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-05-19
           Keywords|                            |openacc, openmp
                 CC|                            |tschwinge at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #3 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to Brecht Sanders from comment #0)
> Several issues when using GCC built against MinGW-w64 for Windows to compile
> gomp test code (see attached minimal source code).
> 
> Code compiles fine with:
> g++ -c -o test.o test.cpp -fopenmp -foffload=nvptx-none
> 
> Linking fails when done like this:
> g++ -o test.exe test.o -lgomp
> mkoffload: fatal error: either '-fopenacc' or '-fopenmp' must be set
> compilation terminated.
> lto-wrapper.exe: fatal error:
> d:/prog/winlibs64-10.3.0/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.
> 0//accel/nvptx-none/mkoffload.exe returned 1 exit status
> compilation terminated.
> d:/prog/winlibs64-10.3.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../
> ../../../x86_64-w64-mingw32/bin/ld.exe: error: lto-wrapper failed
> collect2.exe: error: ld returned 1 exit status

Link with '-fopenacc' or '-fopenmp' instead of '-lgomp'.

> Avoiding LTO seems to work around this and the following links fine:
> g++ -o test.exe test.o -fno-lto -lgomp

That's because "-fno-lto effectively disables offloading" (PR109819).

> When executing test.exe the output starts with:
> libgomp: while loading libgomp-plugin-nvptx.so.1:
> "libgomp-plugin-nvptx.so.1": The specified module could not be found.
> 
> The correct file on Windows is libgomp-plugin-nvptx-1.dll, not
> libgomp-plugin-nvptx.so.1

ACK.  GCC's OpenACC/OpenMP code offloading has only been implemented for/tested
on GNU/Linux systems.  Windows support can certainly be added, but it needs
someone to do it.