[Bug c/116091] New: MinGW-w64 build not building plugin libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116091 Bug ID: 116091 Summary: MinGW-w64 build not building plugin libraries Product: gcc Version: 14.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: brechtsanders at users dot sourceforge.net Target Milestone: --- When building MinGW-w64 builds of GCC 13 or higher natively on Windows (in MSYS2 shell) I noticed the plugin libraries cc1.exe.a and cc1plus.exe.a are no longer built when building with --enable-plugin In fact, make succeeds but make install fails because it can't find these files, but it is trying to install them: /usr/bin/install -c -m 644 cc1.exe.a /R/winlibs-gcc13.2.0-posix-msvcrt-11.0.1_64/inst_gcc-14.1.0/share/gcc/lib/gcc/x86_64-w64-mingw32/14.1.0/plugin/cc1.exe.a /usr/bin/install: cannot stat 'cc1.exe.a': No such file or directory Can you tell me where in the make files it is supposed to be building cc1.exe.a and cc1plus.exe.a ? My configure command looks like this: ./configure --prefix=/R/winlibs-gcc13.2.0-posix-msvcrt-11.0.1_64/inst_gcc-14.1.0/share/gcc --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --enable-offload-targets=nvptx-none --with-pkgversion=MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders --with-tune=generic --enable-checking=release --enable-threads=posix --disable-sjlj-exceptions --disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap --enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath --disable-libstdcxx-debug --disable-version-specific-runtime-libs --with-stabs --disable-symvers --enable-languages=c,c++,fortran,lto,objc,obj-c++ --disable-gold --disable-nls --disable-stage1-checking --disable-win32-registry --disable-multilib --enable-ld --enable-libquadmath --enable-libada --enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string --enable-libgomp --enable-graphite --enable-mingw-wildcard --enable-libstdcxx-time --enable-libstdcxx-pch --with-mpc=/d/Prog/winlibs-gcc13.2.0-posix-msvcrt-11.0.1/custombuilt64 --with-mpfr=/d/Prog/winlibs-gcc13.2.0-posix-msvcrt-11.0.1/custombuilt64 --with-gmp=/d/Prog/winlibs-gcc13.2.0-posix-msvcrt-11.0.1/custombuilt64 --with-isl=/d/Prog/winlibs-gcc13.2.0-posix-msvcrt-11.0.1/custombuilt64 --disable-libstdcxx-backtrace --enable-install-libiberty --enable-__cxa_atexit --without-included-gettext --with-diagnostics-color=auto --enable-clocale=generic --with-libiconv --with-system-zlib --with-build-sysroot=/R/winlibs-gcc13.2.0-posix-msvcrt-11.0.1_64/gcc-14.1.0/mingw-w64 CFLAGS=-D__USE_MINGW_ANSI_STDIO=0 -I/d/Prog/winlibs-gcc13.2.0-posix-msvcrt-11.0.1/custombuilt64/include/libdl-win32 -march=nocona -msahf -mtune=generic -O2 -Wno-error=format CXXFLAGS=-D__USE_MINGW_ANSI_STDIO=0 -Wno-int-conversion -march=nocona -msahf -mtune=generic -O2 LDFLAGS=-pthread -Wl,--no-insert-timestamp -Wl,--dynamicbase -Wl,--high-entropy-va -Wl,--nxcompat -Wl,--tsaware
[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312 --- Comment #6 from Brecht Sanders --- You're right. Sorry I missed that.
[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312 --- Comment #4 from Brecht Sanders --- No, that patch wasn't added for my build, see my build recipe here: https://github.com/brechtsanders/winlibs_recipes/blob/main/recipes/gcc.winlib
[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312 Brecht Sanders changed: What|Removed |Added CC||brechtsanders at users dot sourcef ||orge.net --- Comment #2 from Brecht Sanders --- I have made a native Windows MinGW-w64 build where the lines "gcc_assert (!the_parser);" were commented out in file gcc/cp/parser.cc and got confirmation this successfully works around the issue. See: https://github.com/brechtsanders/winlibs_mingw/issues/199
[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678 --- Comment #10 from Brecht Sanders --- What is the status of GCC support for aarch64-w64-mingw32 ? I just tried GCC 14 snapshot 20240414 and it looks like it's still not supported. Build fails with: *** Configuration aarch64-w64-mingw32 not supported
[Bug target/99913] GCC11 fails to build for MinGW-w64 for Windows 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913 Brecht Sanders changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Brecht Sanders --- I can confirm GCC 13.2.0 builds with MinGW-w64 11.0.1 without explicitly configuring with LDFLAGS="-pthread"
[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678 --- Comment #5 from Brecht Sanders --- Thanks Zac, how can I see what you actually changed? Is there a particular GCC version I can diff https://github.com/ZacWalk/gcc-woarm64 against?
[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678 --- Comment #3 from Brecht Sanders --- Any pointers on which files to edit in order to support aarch64-mingw ? I think it won't require reinventing the wheel as it will probably be a mix of existing *-mingw and aarch64-* stuff...
[Bug target/108678] Windows on ARM64 platform target aarch64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678 --- Comment #2 from Brecht Sanders --- I would love to give it a go if only I knew where to add the support. I actually got a Windows on ARM device hoping I could figure it out, bit it looks I will need tome help. The "Unknown tune used in --with-tune=generic" error is where I'm currently stuck, and I couldn't figure out in which file(s) I need to address this.
[Bug c/108678] New: Windows on ARM64 platform target aarch64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678 Bug ID: 108678 Summary: Windows on ARM64 platform target aarch64-w64-mingw32 Product: gcc Version: 13.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: --- Are there plans to support Windows (using MinGW-w64) on ARM64? The triplet for this platform should be: aarch64-w64-mingw32 I'm trying to build natively on a Windows on ARM device (bootstrapping from LLVM/CLang). Since binutils 2.40 there some support for aarch64 COFF/PE format, and I already built a working binutils with the following supported targets: ld --help|sed -n "s/^.*supported targets: //p" pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64 pe-i386 pei-i386 elf32-i386 elf32-iamcu pdb elf64-little elf64-big elf32-little elf32-big pe-bigobj-i386 pe-aarch64-little pei-aarch64-little srec symbolsrec verilog tekhex binary ihex plugin So it looks like pe-aarch64-little and pei-aarch64-little are listed. I'm don't know if a pe-bigobj-aarch64-little is needed or if it will be supported in the future. My first attempt to get gcc (I tried with source tarball 12.2.0) to configure was changing the following line in gcc/config.gcc: i[34567]86-*-mingw* | x86_64-*-mingw*) to: i[34567]86-*-mingw* | x86_64-*-mingw* | aarch64-*-mingw*) but then I get the following error: Unknown tune used in --with-tune=generic What needs to be changed to get past that?
[Bug target/105506] [12/13 Regression] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #12 from Brecht Sanders --- I couldn't apply that patch. Is that for 12.2.0 ?
[Bug target/105506] [12/13 Regression] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #10 from Brecht Sanders --- I can confirm GCC 12.2.0 builds fine with that patch and without CFLAG -D__USE_MINGW_ACCESS
[Bug pch/105858] MinGW-w64 64-bit build with --libstdcxx-pch: fatal error: cannot write PCH file: required memory segment unavailable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858
--- Comment #8 from Brecht Sanders
---
I seem to be having some success after applying patches based on:
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0010-Fix-using-large-PCH.patch
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0021-PR14940-Allow-a-PCH-to-be-mapped-to-a-different-addr.patch
My patch for GCC 12.2.0 looks like this:
patch -ulbf gcc/config/i386/host-mingw32.cc << EOF
@@ -46,5 +46,2 @@
-/* FIXME: Is this big enough? */
-static const size_t pch_VA_max_size = 128 * 1024 * 1024;
-
/* Granularity for reserving address space. */
@@ -90,5 +87,2 @@
void* res;
- size = (size + va_granularity - 1) & ~(va_granularity - 1);
- if (size > pch_VA_max_size)
-return NULL;
@@ -102,3 +96,3 @@
- res = VirtualAlloc (NULL, pch_VA_max_size,
+ res = VirtualAlloc (NULL, size,
MEM_RESERVE | MEM_TOP_DOWN,
@@ -143,3 +137,2 @@
OSVERSIONINFO version_info;
- int r;
@@ -152,3 +145,3 @@
this to work. We can't change the offset. */
- if ((offset & (va_granularity - 1)) != 0 || size > pch_VA_max_size)
+ if ((offset & (va_granularity - 1)) != 0)
return -1;
@@ -177,21 +170,20 @@
- /* Retry five times, as here might occure a race with multiple gcc's
- instances at same time. */
- for (r = 0; r < 5; r++)
- {
- mmap_addr = MapViewOfFileEx (mmap_handle, FILE_MAP_COPY, 0, offset,
- size, addr);
- if (mmap_addr == addr)
- break;
- if (r != 4)
-Sleep (500);
- }
-
- if (mmap_addr != addr)
+ /* Try mapping the file at \`addr\`. */
+ mmap_addr = MapViewOfFileEx (mmap_handle, FILE_MAP_COPY, 0, offset,
+ size, addr);
+ if (mmap_addr == NULL)
{
- w32_error (__FUNCTION__, __FILE__, __LINE__, "MapViewOfFileEx");
- CloseHandle(mmap_handle);
- return -1;
+ /* We could not map the file at its original address, so let the
+system choose a different one. The PCH can be relocated later. */
+ mmap_addr = MapViewOfFileEx (mmap_handle, FILE_MAP_COPY, 0, offset,
+ size, NULL);
+ if (mmap_addr == NULL)
+ {
+ w32_error (__FUNCTION__, __FILE__, __LINE__, "MapViewOfFileEx");
+ CloseHandle(mmap_handle);
+ return -1;
+ }
}
+ addr = mmap_addr;
return 1;
EOF
[Bug pch/105858] MinGW-w64 64-bit build with --libstdcxx-pch: fatal error: cannot write PCH file: required memory segment unavailable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858 --- Comment #7 from Brecht Sanders --- Any update on this? This issue makes GCC12 really slow on Windows because PCH support doesn't work. If mman-win32 support could be made to work it might solve this issue. The problem is that this requires linking with -lmman (and this flag needs to be near the end of the list of linked libraries)
[Bug pch/105858] MinGW-w64 64-bit build with --libstdcxx-pch: fatal error: cannot write PCH file: required memory segment unavailable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858 --- Comment #5 from Brecht Sanders --- I believe this is issue is cause by the fact that mmap is missing on Windows. In gcc/ggc-common.cc this causes use of default_gt_pch_get_address() as HOST_HOOKS_GT_PCH_GET_ADDRESS which just returns NULL resulting in "cannot write PCH file: required memory segment unavailable". Though mmap doesn't exist, it isn't that hard to emulate, as can be seen in https://github.com/alitrack/mman-win32 , so maybe some code is needed to use the Windows memory mapping mechanism. I did try to build against https://github.com/alitrack/mman-win32, but I ran into the issue that this requires linking with the library mman-win32, but passing it to LDFLAGS doesn't work as it's not near the end of the linker command and link order is important on Windows/MinGW.
[Bug pch/105858] MinGW-w64 64-bit build with --libstdcxx-pch: fatal error: cannot write PCH file: required memory segment unavailable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858 --- Comment #4 from Brecht Sanders --- Any update on this issue? I see performance complaints from several people in GCC12+MinGW-w64 being much slower in the build without precompiled headers (see: https://github.com/brechtsanders/winlibs_mingw/issues/107)
[Bug target/106728] Cannot Compile EXE on Shared Network Drive (Windows, MinGW)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106728 Brecht Sanders changed: What|Removed |Added CC||brechtsanders at users dot sourcef ||orge.net --- Comment #7 from Brecht Sanders --- I can confirm it works with the -S flag. Version of binutils is 2.39, so indeed something ma be broken since 2.38.
[Bug pch/105858] MinGW-w64 64-bit build with --libstdcxx-pch: fatal error: cannot write PCH file: required memory segment unavailable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858 --- Comment #3 from Brecht Sanders --- Some information I received related to this issue: On 01/08/2022 14:52, Luis Dallos wrote: > > PCH has had issues for as long as I can remember, see for example: > > * > https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0010-Fix-using-large-PCH.patch > > The msys2 team commited in msys2/MINGW-packages@52908ed an additional patch > in order to fix PCH relocation issues. > > https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0021-PR14940-Allow-a-PCH-to-be-mapped-to-a-different-addr.patch > > See also: > > msys2/MINGW-packages#11582 (comment) > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594556.html
[Bug pch/105858] MinGW-w64 64-bit build with --libstdcxx-pch: fatal error: cannot write PCH file: required memory segment unavailable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858 --- Comment #2 from Brecht Sanders --- Just checked, issue is still present in snapshot 12-20220723. Anybody able to confirm the issue or know what the status is?
[Bug pch/105858] MinGW-w64 64-bit build with --libstdcxx-pch: fatal error: cannot write PCH file: required memory segment unavailable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858 --- Comment #1 from Brecht Sanders --- Any news on this? I am not the only one experiencing this. See also: https://github.com/brechtsanders/winlibs_mingw/issues/108
[Bug target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #7 from Brecht Sanders --- Thank you for sharing your insights. I can confirm building with CFLAGS="-D__USE_MINGW_ACCESS" works. So I guess the question that remains is: Where is -D__USE_MINGW_ACCES missing in the configuration of GCC 12? It would seem to me the answer lies in code added since GCC 11 that contains access()/X_OK.
[Bug c/105858] New: MinGW-w64 64-bit build with --libstdcxx-pch: fatal error: cannot write PCH file: required memory segment unavailable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105858 Bug ID: 105858 Summary: MinGW-w64 64-bit build with --libstdcxx-pch: fatal error: cannot write PCH file: required memory segment unavailable Product: gcc Version: 12.1.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: --- When building the Windows 64-bit version of GCC 12.1.0 against MinGW-w64 build with --libstdcxx-pch the following error occurs: In file included from R:/winlibs64_stage/gcc-12.1.0/libstdc++-v3/include/precompiled/extc++.h:82: R:/winlibs64_stage/gcc-12.1.0/build_mingw/x86_64-w64-mingw32/libstdc++-v3/include/ext/enc_filebuf.h:63:1: fatal error: cannot write PCH file: required memory segment unavailable 63 | } // namespace | ^ compilation terminated. This error does not happen when building the 32-bit version.
[Bug target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #5 from Brecht Sanders --- Created attachment 53088 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53088=edit Process Monitor when running `gcc -print-prog-name=cc1` Process Monitor when running `gcc -print-prog-name=cc1`
[Bug target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #4 from Brecht Sanders --- I just ran `gcc -print-prog-name=cc1` and saw the output was only `cc1` while on working versions it reports a full path to `cc1.exe` (e.g. `d:/prog/winlibs64_stage/custombuilt/share/gcc/bin/../libexec/gcc/x86_64-w64-mingw32/12.1.0/cc1.exe`). In this minimal case Process Monitor also shows the handle to `cc1.exe` is successfully opened but the subsequent calls to QueryInformationVolume and QueryAllInformationFile fail with BUFFER_OVERFLOW.
[Bug target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #3 from Brecht Sanders --- Created attachment 53046 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53046=edit ProcessMonitor filtered on occurrence of "cc1"
[Bug target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #2 from Brecht Sanders --- I did an additional test to see where gcc.exe is looking for cc1.exe using Process Monitor. This was using a i686 UCRT build of GCC against MinGW-w64 installed under: D:\Prog\winlibs32ucrt_stage\mingw32 I'm on Windows 11. First it looks here (opening the file handle with CreateFile): D:\Prog\winlibs32ucrt_stage\mingw32\libexec\gcc\i686-w64-mingw32ucrt\12.1.0\cc1.exe This actually exists. But then a call to QueryInformationVolume fails with BUFFER OVERFLOW and then agian another call to QueryAllInformationFile also fails with BUFFER OVERFLOW Then it goes on to look for cc1.exe in places where it doesn't exist.
[Bug target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 --- Comment #1 from Brecht Sanders --- Apparently this issue is not related to the .exe extension, but rather to where it is looking for cc1.exe. If somepath/bin is where gcc.exe lives than it helpst to add somepath/libexec/gcc/x86_64-w64-mingw32/12.1.0 to the PATH to around this issue. But this should not be necessary. I also find it strange that I don't have this issue with the MSVCRT build of MinGW-w64, but I do have the issue with the UCRT build of MinGW-w64. Is there a different path or architecture triplet at play for UCRT?
[Bug c/105506] New: Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506 Bug ID: 105506 Summary: Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory Product: gcc Version: 12.1.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: --- Building GCC 12.1.0 against MinGW-w64 fails with (error taken from config.log for libgcc folder): fatal error: cannot execute 'cc1': CreateProcess: No such file or directory in libgcc I believe this fails because CreateProcess() probably expects this to be cc1.exe Where should this be fixed?
[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #7 from Brecht Sanders --- I'm still trying to understand how it all works, but to avoid \n versus \r\n issues on Windows I would already recommend these changes: ``` patch -ulbf gcc/go/gofrontend/gogo.cc << EOF @@ -5252,3 +5252,3 @@ std::ofstream out; - out.open(this->c_header_.c_str()); + out.open(this->c_header_.c_str(), std::ios_base::binary); if (out.fail()) EOF patch -ulbf gcc/go/gofrontend/ast-dump.cc << EOF @@ -197,3 +197,3 @@ dumpname += ".dump.ast"; - out.open(dumpname.c_str()); + out.open(dumpname.c_str(), std::ios_base::binary); EOF ``` Unfortanately this doesn't solve the issue though. I couldn't figure out yet where the code is that makes go_read_export_data in gcc/go/go-backend.cc skip the part before the magic string...
[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #5 from Brecht Sanders --- The generated internal/cpu.gox looks like the below dump. Can you see what the issue is with the magic string? ``` : 6486 0100 5809 0200 d...X... 0010: 0500 2f34 /4.. 0020: 1c09 3c00 <... 0030: 4000 3040 7633 3b0a @.0@v3;. 0040: 7061 636b 6167 6520 6370 750a 706b 6770 package cpu.pkgp 0050: 6174 6820 696e 7465 726e 616c 2f63 7075 ath internal/cpu 0060: 0a69 6e69 7420 6370 7520 696e 7465 726e .init cpu intern 0070: 616c 5f31 6370 752e 2e69 6d70 6f72 740a al_1cpu..import. 0080: 7479 7065 7320 3134 2032 2033 3120 3130 types 14 2 31 10 0090: 2032 3220 3435 2034 3031 2032 3539 2031 22 45 401 259 1 00a0: 3531 2038 3920 3131 3220 3530 3320 3235 51 89 112 503 25 00b0: 2032 3120 3232 0a74 7970 6520 3120 2243 21 22.type 1 "C 00c0: 6163 6865 4c69 6e65 5061 6422 203c 7479 acheLinePad" .type 2 (). 00e0: 7479 7065 2033 2028 3f20 3c74 7970 6520 type 3 (? ).type 4 str ```
[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #3 from Brecht Sanders --- What exactly would be the file(s) being opened in this case? When can we expect the libgo cleanup needed for MinGW(-w64) support?
[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #1 from Brecht Sanders --- P.S.: This attempt was with snapshot version 12-20220417
[Bug go/105302] New: gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
Bug ID: 105302
Summary: gccgo for Windows using MinGW-w64
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: brechtsanders at users dot sourceforge.net
CC: cmang at google dot com
Target Milestone: ---
I thought I's give building gccgo for Windows using MinGW-w64 another try.
First of all I had to change `configure` to allow me to do that:
```
patch -ulbf configure << EOF
@@ -3577,3 +3577,3 @@
case "\${target}" in
-*-*-darwin* | *-*-cygwin* | *-*-mingw* | bpf-* )
+*-*-darwin* | *-*-cygwin* | bpf-* )
unsupported_languages="\$unsupported_languages go"
@@ -3609,3 +3609,3 @@
;;
-*-*-cygwin* | *-*-mingw*)
+*-*-cygwin*)
noconfigdirs="\$noconfigdirs target-libgo"
EOF
```
Then I added `go` to `--enable-languages=` and I added `--enable-libgo` to the
`./configure` line.
It got pretty far this time, and I actually go a working `gccgo.exe`, but libgo
wasn't such a success:
```
libtool: compile:
/d/Prog/winlibs64-11.2.0ucrt/home/gcc-12-20220417/build_mingw/./gcc/gccgo
-B/d/Prog/winlibs64-11.2.0ucrt/home/gcc-12-20220417/build_mingw/./gcc/
-L/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/lib
-L/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/mingw/lib -isystem
/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/include
-isystem /R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/mingw/include
-B/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/bin/
-B/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/lib/
-isystem
/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/include
-isystem
/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/sys-include
--sysroot=/d/Prog/winlibs64-11.2.0ucrt/home/gcc-12-20220417/build_mingw/mingw-w64
-minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/bytealg
../../../libgo/go/internal/bytealg/bytealg.go
../../../libgo/go/internal/bytealg/compare_native.go
../../../libgo/go/internal/bytealg/count_generic.go
../../../libgo/go/internal/bytealg/equal_generic.go
../../../libgo/go/internal/bytealg/equal_native.go
../../../libgo/go/internal/bytealg/gccgo.go
../../../libgo/go/internal/bytealg/index_native.go
../../../libgo/go/internal/bytealg/indexbyte_native.go -DDLL_EXPORT -o
internal/.libs/bytealg.o
../../../libgo/go/internal/bytealg/bytealg.go:8:21: warning: ./internal/cpu:
Permission denied
8 | "internal/cpu"
| ^
../../../libgo/go/internal/bytealg/bytealg.go:8:21: error: error in import data
at 2329: invalid magic string
```
I feel we're getting closer. Any idea what caused this error?
[Bug d/104659] New: msvcUsedUCRT in libphobos/libdruntime/config/mingw/msvc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104659 Bug ID: 104659 Summary: msvcUsedUCRT in libphobos/libdruntime/config/mingw/msvc.c Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: brechtsanders at users dot sourceforge.net Target Milestone: --- When compiling for D language I got an error on libphobos/libdruntime/config/mingw/msvc.c that msvcUsedUCRT is not defined. When I change this to msvcUsesUCRT compilation continues.
[Bug d/104654] New: Errors in gthread.d when building against MinGW-w64 with --enable-threads=posix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104654 Bug ID: 104654 Summary: Errors in gthread.d when building against MinGW-w64 with --enable-threads=posix Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: brechtsanders at users dot sourceforge.net Target Milestone: --- When building GCC (recently tried 11.2 snapshot 20220219) against MinGW-w64 with --enable-threads=posix the following D compiler errors occur: r:\winlibs64-11.2.0ucrt\gcc-11-20220219\libphobos\libdruntime\gcc\gthread.d:46:30: error: undefined identifier 'PTHREAD_ONCE_INIT', did you mean variable 'GTHREAD_ONCE_INIT'? 46 | enum GTHREAD_ONCE_INIT = PTHREAD_ONCE_INIT; | ^ r:\winlibs64-11.2.0ucrt\gcc-11-20220219\libphobos\libdruntime\gcc\gthread.d:44:29: error: undefined identifier 'pthread_key_t' 44 | alias __gthread_key_t = pthread_key_t; | ^ r:\winlibs64-11.2.0ucrt\gcc-11-20220219\libphobos\libdruntime\gcc\gthread.d:45:30: error: undefined identifier 'pthread_once_t' 45 | alias __gthread_once_t = pthread_once_t; | ^ >From what I gather things like pthread_key_t and pthread_once_t should probably be defined in libphobos/libdruntime/core/sys/posix/sys/types.d and PTHREAD_ONCE_INIT in libphobos/libdruntime/core/sys/posix/pthread.d I noticed in libphobos/libdruntime/core/sys/posix/sys/types.d there is no specific version() case for Windows/MinGW with POSIX threads.
[Bug target/100293] MinGW-w64 of nvptx offload engine fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100293 --- Comment #9 from Brecht Sanders --- Any update on this? Issue still exists today (in GCC 11.2.0 and in latest snapshot 11.2.1-20210814). Both when building gcc on Windows for nvptx as well as the offload engine for nvptx there is an error like this in nvptx-none/libatomic/config.log: configure:3736: $? = 1 configure:3756: checking whether the C compiler works configure:3778: /R/winlibs64_stage/nvptx-gcc-11-20210814/gcc-11-20210814/build_nvptx_gcc/./gcc/xgcc -B/R/winlibs64_stage/nvptx-gcc-11-20210814/gcc-11-20210814/build_nvptx_gcc/./gcc/ -nostdinc -B/R/winlibs64_stage/nvptx-gcc-11-20210814/gcc-11-20210814/build_nvptx_gcc/nvptx-none/newlib/ -isystem /R/winlibs64_stage/nvptx-gcc-11-20210814/gcc-11-20210814/build_nvptx_gcc/nvptx-none/newlib/targ-include -isystem /R/winlibs64_stage/nvptx-gcc-11-20210814/gcc-11-20210814/newlib/libc/include -B/R/winlibs64_stage/inst_nvptx-gcc-11-20210814/share/nvptx-gcc/nvptx-none/bin/ -B/R/winlibs64_stage/inst_nvptx-gcc-11-20210814/share/nvptx-gcc/nvptx-none/lib/ -isystem /R/winlibs64_stage/inst_nvptx-gcc-11-20210814/share/nvptx-gcc/nvptx-none/include -isystem /R/winlibs64_stage/inst_nvptx-gcc-11-20210814/share/nvptx-gcc/nvptx-none/sys-include -g -O2 conftest.c >&5 error reading C:\Temp\ccqpNwjZ.o collect2.exe: error: ld returned 1 exit status
[Bug target/99401] Rebuilding the compiler with itself fails at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401 Brecht Sanders changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Brecht Sanders --- Recently released version 11.1.0 does build for Windows 32-bit with MinGW-w64 without issues.
[Bug target/100293] MinGW-w64 of nvptx offload engine fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100293 --- Comment #8 from Brecht Sanders --- Additional test: Running this manually (in MSYS2 shell) also fails: R:/winlibs32_stage/gcc-offload-nvptx-11.1.0/gcc-11.1.0/build_win_offload-nvptx/gcc/as -v -m sm_35 -o 'R:\winlibs32_stage\_TMP_\ccYJWYIt.o' 'R:\winlibs32_stage\_TMP_\ccu9TSoP.s' nvptx-as: cannot open input ptx file
[Bug target/100293] MinGW-w64 of nvptx offload engine fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100293
--- Comment #7 from Brecht Sanders
---
I ran the following commands based on what was in config.log
cat > conftest.c << EOF
/* confdefs.h */
#define PACKAGE_NAME "GNU Atomic Library"
#define PACKAGE_TARNAME "libatomic"
#define PACKAGE_VERSION "1.0"
#define PACKAGE_STRING "GNU Atomic Library 1.0"
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL "http://www.gnu.org/software/libatomic/;
#define PACKAGE "libatomic"
#define VERSION "1.0"
/* end confdefs.h. */
int
main ()
{
;
return 0;
}
EOF
/R/winlibs32_stage/gcc-offload-nvptx-11.1.0/gcc-11.1.0/build_win_offload-nvptx/./gcc/xgcc
-B/R/winlibs32_stage/gcc-offload-nvptx-11.1.0/gcc-11.1.0/build_win_offload-nvptx/./gcc/
-B/R/winlibs32_stage/inst_gcc-offload-nvptx-11.1.0/share/gcc/nvptx-none/bin/
-B/R/winlibs32_stage/inst_gcc-offload-nvptx-11.1.0/share/gcc/nvptx-none/lib/
-isystem
/R/winlibs32_stage/inst_gcc-offload-nvptx-11.1.0/share/gcc/nvptx-none/include
-isystem
/R/winlibs32_stage/inst_gcc-offload-nvptx-11.1.0/share/gcc/nvptx-none/sys-include
-g -O2 conftest.c -v
and the result was:
Reading specs from
R:/winlibs32_stage/gcc-offload-nvptx-11.1.0/gcc-11.1.0/build_win_offload-nvptx/gcc/specs
COLLECT_GCC=R:\winlibs32_stage\gcc-offload-nvptx-11.1.0\gcc-11.1.0\build_win_offload-nvptx\gcc\xgcc.exe
COLLECT_LTO_WRAPPER=R:/winlibs32_stage/gcc-offload-nvptx-11.1.0/gcc-11.1.0/build_win_offload-nvptx/gcc/lto-wrapper.exe
Target: nvptx-none
Configured with: ../configure
--prefix=/R/winlibs32_stage/inst_gcc-offload-nvptx-11.1.0/share/gcc
--build=i686-w64-mingw32 --host=i686-w64-mingw32 --target=nvptx-none
--enable-as-accelerator-for=i686-w64-mingw32 --with-pkgversion='built by
Brecht Sanders'
--with-build-time-tools=/d/Prog/winlibs32_stage/custombuilt/share/nvptx-tools/nvptx-none/bin
--with-gnu-as --with-gnu-ld --disable-serial-configure
--enable-checking=release --without-libbacktrace --without-included-gettext
--without-cuda-driver --enable-multiarch --enable-newlib-io-long-long
--enable-linker-build-id --enable-multilib --disable-sjlj-exceptions
--disable-libunwind-exceptions --disable-libgomp
--enable-languages=c,c++,lto,objc,obj-c++,d
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (built by Brecht Sanders)
COLLECT_GCC_OPTIONS='-B'
'R:/winlibs32_stage/gcc-offload-nvptx-11.1.0/gcc-11.1.0/build_win_offload-nvptx/gcc/'
'-B'
'R:/winlibs32_stage/inst_gcc-offload-nvptx-11.1.0/share/gcc/nvptx-none/bin/'
'-B'
'R:/winlibs32_stage/inst_gcc-offload-nvptx-11.1.0/share/gcc/nvptx-none/lib/'
'-isystem'
'R:/winlibs32_stage/inst_gcc-offload-nvptx-11.1.0/share/gcc/nvptx-none/include'
'-isystem'
'R:/winlibs32_stage/inst_gcc-offload-nvptx-11.1.0/share/gcc/nvptx-none/sys-include'
'-g' '-O2' '-v' '-dumpdir' 'a-'
R:/winlibs32_stage/gcc-offload-nvptx-11.1.0/gcc-11.1.0/build_win_offload-nvptx/gcc/cc1.exe
-quiet -v -iprefix
r:\winlibs32_stage\gcc-offload-nvptx-11.1.0\gcc-11.1.0\build_win_offload-nvptx\gcc\../lib/gcc/i686-w64-mingw32/11.1.0D:/Prog/msys64/accel/nvptx-none/
-isystem
R:/winlibs32_stage/gcc-offload-nvptx-11.1.0/gcc-11.1.0/build_win_offload-nvptx/gcc/include
-isystem
R:/winlibs32_stage/gcc-offload-nvptx-11.1.0/gcc-11.1.0/build_win_offload-nvptx/gcc/include-fixed
-isystem
R:/winlibs32_stage/inst_gcc-offload-nvptx-11.1.0/share/gcc/nvptx-none/include
-isystem
R:/winlibs32_stage/inst_gcc-offload-nvptx-11.1.0/share/gcc/nvptx-none/sys-include
conftest.c -quiet -dumpdir a- -dumpbase conftest.c -dumpbase-ext .c -g -O2
-version -o R:\winlibs32_stage\_TMP_\ccu9TSoP.s
GNU C17 (built by Brecht Sanders) version 11.1.0 (nvptx-none)
compiled by GNU C version 11.1.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"R:/winlibs32_stage/inst_gcc-offload-nvptx-11.1.0/share/gcc/nvptx-none/include"
ignoring nonexistent directory
"R:/winlibs32_stage/inst_gcc-offload-nvptx-11.1.0/share/gcc/nvptx-none/sys-include"
ignoring nonexistent directory
"r:\winlibs32_stage\gcc-offload-nvptx-11.1.0\gcc-11.1.0\build_win_offload-nvptx\gcc\../lib/gcc/i686-w64-mingw32/11.1.0D:/Prog/msys64/accel/nvptx-none/include"
ignoring nonexistent directory
"r:\winlibs32_stage\gcc-offload-nvptx-11.1.0\gcc-11.1.0\build_win_offload-nvptx\gcc\../lib/gcc/i686-w64-mingw32/11.1.0D:/Prog/msys64/accel/nvptx-none/include-fixed"
ignoring nonexistent directory
"r:\winlibs32_stage\gcc-offload-nvptx-11.1.0\gcc-11.1.0\build_win_offload-nvptx\gcc\../lib/gcc/i686-w64-mingw32/11.1.0D:/Prog/msys64/accel/nvptx-none/../../../../../../nvptx-none/sys-include"
ignoring nonexistent directory
"r:\winlibs32_stage\gcc-offload-nvptx-11.1.0\gcc-11.1.0\build_win_offload-nvptx\gcc\../lib/gcc/i686-w64-mingw32/11.1.0D:/Prog/msys64/accel/nvptx-none/../../../../../../nvptx-none/include"
ignoring nonexistent directory
[Bug target/100293] MinGW-w64 of nvptx offload engine fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100293 --- Comment #6 from Brecht Sanders --- Yes, that folder exists and that's where my TMP and TEMP environment variables point to. I also tried to point them to a folder on the C: drive, as R: is a RAM drive and I wanted to exclude that that was the issue, but the result was the same: build fails in the same place when configuring libatomic.
[Bug c/100293] MinGW-w64 of nvptx offload engine fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100293 --- Comment #3 from Brecht Sanders --- My bad, yes I was using nvptx-tools (master from https://github.com/MentorEmbedded/nvptx-tools). my configure command for nvptx offload engine looks like this ./configure --prefix=/R/winlibs64_stage/inst_gcc-offload-nvptx-11.1.0/share/gcc --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=nvptx-none --enable-as-accelerator-for=x86_64-w64-mingw32 --with-build-time-tools=/d/Prog/winlibs64_stage/custombuilt/share/nvptx-tools/nvptx-none/bin --with-gnu-as --with-gnu-ld --disable-serial-configure --enable-checking=release --without-libbacktrace --without-included-gettext --without-cuda-driver --enable-multiarch --enable-newlib-io-long-long --enable-linker-build-id --enable-multilib --disable-sjlj-exceptions --disable-libunwind-exceptions --disable-libgomp --enable-languages=c,c++,lto,objc,obj-c++,d So yes, --disable-sjlj-exceptions --enable-newlib-io-long-long is there. Note that the same build scripts worked fine with GCC 10.3.0 and older.
[Bug c/100293] MinGW-w64 of nvptx offload engine fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100293 --- Comment #1 from Brecht Sanders --- Also tried with unpatched binutils 2.36.1, same outcome. Building GCC targetting nvptx (--target=nvptx-none) also stops with the same error. libatomic/config.log reports: configure:3756: checking whether the C compiler works configure:3778: /R/winlibs64_stage/nvptx-gcc-11.1.0/gcc-11.1.0/build_nvptx_gcc/./gcc/xgcc -B/R/winlibs64_stage/nvptx-gcc-11.1.0/gcc-11.1.0/build_nvptx_gcc/./gcc/ -nostdinc -B/R/winlibs64_stage/nvptx-gcc-11.1.0/gcc-11.1.0/build_nvptx_gcc/nvptx-none/newlib/ -isystem /R/winlibs64_stage/nvptx-gcc-11.1.0/gcc-11.1.0/build_nvptx_gcc/nvptx-none/newlib/targ-include -isystem /R/winlibs64_stage/nvptx-gcc-11.1.0/gcc-11.1.0/newlib/libc/include -B/R/winlibs64_stage/inst_nvptx-gcc-11.1.0/share/nvptx-gcc/nvptx-none/bin/ -B/R/winlibs64_stage/inst_nvptx-gcc-11.1.0/share/nvptx-gcc/nvptx-none/lib/ -isystem /R/winlibs64_stage/inst_nvptx-gcc-11.1.0/share/nvptx-gcc/nvptx-none/include -isystem /R/winlibs64_stage/inst_nvptx-gcc-11.1.0/share/nvptx-gcc/nvptx-none/sys-include -g -O2 conftest.c >&5 error reading R:\winlibs64_stage\_TMP_\ccKq7IbV.o collect2.exe: error: ld returned 1 exit status
[Bug c/100293] New: MinGW-w64 of nvptx offload engine fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100293 Bug ID: 100293 Summary: MinGW-w64 of nvptx offload engine fails Product: gcc Version: 11.1.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 50691 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50691=edit libatomic/config.log When doing a Windows native build of the GCC 11.1.0 nvptx offload engine on Windows using MinGW-w64 and binutils 2.36.1 with: --target=nvptx-none --enable-as-accelerator-for=x86_64-w64-mingw32 or: --target=nvptx-none --enable-as-accelerator-for=i686-w64-mingw32 the following error is shown: configure: error: in `/R/winlibs64_stage/gcc-offload-nvptx-11.1.0/gcc-11.1.0/build_win_offload-nvptx/nvptx-none/libatomic': configure: error: C compiler cannot create executables See `config.log' for more details Note that binutils is version 2.36.1 but had patches applied as advises in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 as these were needed to build the earlier GCC 11 snapshots.
[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
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=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 target/100141] Unable to build amdgcn-amdhsa offload accelerator for MinGW-w64 for both Windows 32-bit and 64-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100141 --- Comment #2 from Brecht Sanders --- My plan was to build entirely without LLVM if possible, but if needed to just build the offload accelerator I do have it available (though I need to check if I have this target available). What options are needed to tell configure where to look for the assembler and linker?
[Bug c/100141] New: Unable to build amdgcn-amdhsa offload accelerator for MinGW-w64 for both Windows 32-bit and 64-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100141 Bug ID: 100141 Summary: Unable to build amdgcn-amdhsa offload accelerator for MinGW-w64 for both Windows 32-bit and 64-bit 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 50625 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50625=edit amdgcn-amdhsa/libgcc/config.log When I try to build the GCC amdgcn-amdhsa offload accelerator for MinGW-w64 for both Windows 32-bit (--target=amdgcn-amdhsa --enable-as-accelerator-for=i686-w64-mingw32) and 64-bit (--target=amdgcn-amdhsa --enable-as-accelerator-for=x86_64-w64-mingw32). This has been the case all versions I tried (last attempt was 10.3.0). The output I get is: checking for suffix of object files... configure: error: in `/R/winlibs64-10.3.0/gcc-offload-amdgcn-10.3.0/gcc-10.3.0/build_win_offload-amdgcn/amdgcn-amdhsa/libgcc': configure: error: cannot compute suffix of object files: cannot compile See attached amdgcn-amdhsa/libgcc/config.log The full command line (for Windows 64-bit) looks like this: ../configure --prefix=/R/winlibs64-10.3.0/inst_gcc-offload-amdgcn-10.3.0/share/gcc --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=amdgcn-amdhsa --enable-as-accelerator-for=x86_64-w64-mingw32 --with-build-time-tools=/d/Prog/winlibs64-10.3.0/custombuilt/share/amdgcn-tools/amdgcn-amdhsa/bin --with-gnu-as --with-gnu-ld --disable-serial-configure --enable-checking=release --without-libbacktrace --without-included-gettext --without-cuda-driver --enable-multiarch --enable-newlib-io-long-long --enable-linker-build-id --with-newlib --disable-sjlj-exceptions --disable-libunwind-exceptions --disable-libgomp --enable-languages=c,c++,lto,objc,obj-c++,d CFLAGS="-I/d/Prog/winlibs64-10.3.0/custombuilt/include/mman-win32" LDFLAGS="-Wl,--as-needed -lmman"
[Bug target/99913] GCC11 fails to build for MinGW-w64 for Windows 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913 --- Comment #3 from Brecht Sanders --- Just to clarify: libwinpthread is built as part of the GCC build against MinGW-w64. MinGW-w64 also already has a libwinpthread (including libwinpthread-1.dll which can be found in the PATH).
[Bug target/99913] GCC11 fails to build for MinGW-w64 for Windows 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913 --- Comment #2 from Brecht Sanders --- By the time I get to that error the build process already generated these files: - mingw-w64/mingw/lib/libwinpthread.a - mingw-w64/mingw/lib/libwinpthread.dll.a - mingw-w64/mingw/lib/libwinpthread.la However I couldn't find a matching DLL, which I assume should be here: - mingw-w64/mingw/bin/libwinpthread-1.dll
[Bug c/99913] New: GCC11 fails to build for MinGW-w64 for Windows 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913 Bug ID: 99913 Summary: GCC11 fails to build for MinGW-w64 for Windows 32-bit Product: gcc Version: 11.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 50509 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50509=edit i686-w64-mingw32/libgomp/config.log When building GCC 11 (including latest snapshot 20210404) against MinGW-w64 for Windows 32-bit using an existing MinGW-w64 Windows 32-bit gcc configure stops with the following error: configure: error: unsupported system, cannot find sizeof (omp_lock_t) This error is logged to file i686-w64-mingw32/libgomp/config.log which I have attached. At first glance it seems like it's not finding symbols that require -lwinpthread Note that there are no issues building GCC 11 against MinGW-w64 for Windows 64-bit.
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595 --- Comment #10 from Brecht Sanders --- I thought MinGW-w64 is it's own C library. It is found by GCC build process because the folder mingw exists in the location specified with --with-build-sysroot CppRuntime_Gcc is mentioned in the predefs, why would CRuntime_Gcc not be defined then?
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595 --- Comment #8 from Brecht Sanders --- predefs GNU D_Version2 LittleEndian GNU_SEH_Exceptions GNU_EMUTLS GNU_StackGrowsDown GNU_InlineAsm D_LP64 D_PIC assert D_ModuleInfo D_Exceptions D_TypeInfo all X86_64 D_HardFloat Windows MinGW Win64 CppRuntime_Gcc
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595
--- Comment #6 from Brecht Sanders
---
The patch for gcc/config/i386/t-cygming added a line:
winnt-d.o: config/winnt-d.c
I changed it to:
winnt-d.o: config/i386/winnt-d.c
Then I got one step further.
Output is now:
libtool: compile: /R/winlibs64_stage/gcc-10-20210320/build_mingw/./gcc/gdc
-B/R/winlibs64_stage/gcc-10-20210320/build_mingw/./gcc/
-L/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/lib
-L/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/mingw/lib -isystem
/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/include
-isystem /R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/mingw/include
-B/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/bin/
-B/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/lib/
-isystem
/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/include
-isystem
/R/winlibs64_stage/inst_gcc-10-20210320/share/gcc/x86_64-w64-mingw32/sys-include
--sysroot=/R/winlibs64_stage/gcc-10-20210320/build_mingw/mingw-w64 -DDLL_EXPORT
-Wall -frelease -O2 -g -nostdinc -I ../../../../libphobos/libdruntime -I . -c
../../../../libphobos/libdruntime/core/demangle.d -fversion=Shared -o
core/.libs/demangle.o
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:134:5:
error: undefined identifier 'FILE'
134 | int fwprintf(FILE* stream, in wchar_t* format, ...);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:136:5:
error: undefined identifier 'FILE'
136 | int fwscanf(FILE* stream, in wchar_t* format, ...);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:139:5:
error: undefined identifier 'FILE'
139 | int vfwprintf(FILE* stream, in wchar_t* format, va_list arg);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:141:5:
error: undefined identifier 'FILE'
141 | int vfwscanf(FILE* stream, in wchar_t* format, va_list arg);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:177:12:
error: undefined identifier 'FILE'
177 | wint_t fgetwc(FILE* stream);
|^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:179:12:
error: undefined identifier 'FILE'
179 | wint_t fputwc(wchar_t c, FILE* stream);
|^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:183:10:
error: undefined identifier 'FILE'
183 | wchar_t* fgetws(wchar_t* s, int n, FILE* stream);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:185:10:
error: undefined identifier 'FILE'
185 | int fputws(in wchar_t* s, FILE* stream);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:195:12:
error: undefined identifier 'FILE'
195 | wint_t getwc(FILE* stream){ return fgetwc(stream);}
|^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:197:12:
error: undefined identifier 'FILE'
197 | wint_t putwc(wchar_t c, FILE* stream) { return fputwc(c, stream); }
|^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:204:12:
error: undefined identifier 'FILE'
204 | wint_t ungetwc(wint_t c, FILE* stream);
|^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\wchar_.d:213:16:
error: undefined identifier 'FILE'
213 | intfwide(FILE* stream, int mode);
|^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\stdio.d:1140:16:
error: undefined identifier 'FILE'
1140 | @trusted FILE* tmpfile(); // No unsafe pointer manipulation.
|^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\stdio.d:1145:7:
error: undefined identifier 'FILE'
1145 | int fclose(FILE* stream);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\stdio.d:1151:11:
error: undefined identifier 'FILE'
1151 | int fflush(FILE* stream);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\stdio.d:1155:7:
error: undefined identifier 'FILE'
1155 | FILE* fopen(scope const char* filename, scope const char* mode);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\stdio.d:1157:7:
error: undefined identifier 'FILE'
1157 | FILE* freopen(scope const char* filename, scope const char* mode, FILE*
stream);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\stdio.d:1157:7:
error: undefined identifier 'FILE'
1157 | FILE* freopen(scope const char* filename, scope const char* mode, FILE*
stream);
| ^
r:\winlibs64_stage\gcc-10-20210320\libphobos\libdruntime\core\stdc\stdio.d:1160:6:
error: undefined identifier 'FILE'
1160 |
[Bug d/91595] Version (Windows) is not defined in GCC D Compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595 Brecht Sanders changed: What|Removed |Added CC||brechtsanders at users dot sourcef ||orge.net --- Comment #4 from Brecht Sanders --- I tried to build gcc 10 snapshot 20210320 for Windows 64-bit with the proposed patch. First I got this error: make[2]: Entering directory '/R/winlibs64_stage/gcc-10-20210320/build_mingw/gcc'make[2]: *** No rule to make target 'config/winnt-d.c', needed by 'winnt-d.o'. Stop. After copying the file manually there like this: mkdir -p build_mingw/gcc/config cp -u gcc/config/i386/winnt-d.c build_mingw/gcc/config/ I got this error: d:/prog/winlibs64_stage/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.0.1/../../../../x86_64-w64-mingw32/bin/ld.exe: winnt-d.o:R:\winlibs64_stage\gcc-10-20210320\build_mingw\gcc/config/winnt-d.c:60: multiple definition of `targetdm'; winnt-d.o:R:\winlibs64_stage\gcc-10-20210320\build_mingw\gcc/config/winnt-d.c:60: first defined here collect2.exe: error: ld returned 1 exit status
[Bug target/99401] Rebuilding the compiler with itself fails at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401 --- Comment #5 from Brecht Sanders --- *** Bug 97618 has been marked as a duplicate of this bug. ***
[Bug c/97618] undefined reference to LC11 building for target MinGW-w64 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618 Brecht Sanders changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #5 from Brecht Sanders --- Seems to be the same issue as 99401. *** This bug has been marked as a duplicate of bug 99401 ***
[Bug target/99401] GCC11 MinGW-w64 32-bit build fails with undefined reference to `LC0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401 --- Comment #2 from Brecht Sanders --- Created attachment 50302 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50302=edit gcc -v
[Bug c++/99401] New: GCC11 MinGW-w64 32-bit build fails with undefined reference to `LC0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401 Bug ID: 99401 Summary: GCC11 MinGW-w64 32-bit build fails with undefined reference to `LC0' Product: gcc Version: 11.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 50301 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50301=edit make output When building GCC11 (last tested with 11-20210228) for Windows 32-bit with MinGW-w64 the build fails with undefined references to LC0/LC1/LC2/LC3. My build was done using the following configure command: ../configure --prefix=/R/winlibs32_stage/inst_gcc-11-20210228/share/gcc --build=i686-w64-mingw32 --host=i686-w64-mingw32 --with-pkgversion=MinGW-W64 i686-posix-dwarf, built by Brecht Sanders --with-tune=generic --enable-checking=release --enable-threads=posix --with-dwarf2 --disable-sjlj-exceptions --disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap --enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath --disable-libstdcxx-pch --enable-libstdcxx-time=yes --disable-libstdcxx-debug --disable-version-specific-runtime-libs --with-stabs --disable-symvers --enable-languages=c,c++,lto,objc,obj-c++,d --disable-gold --disable-nls --disable-stage1-checking --disable-win32-registry --disable-multilib --enable-ld --enable-libquadmath --enable-libada --enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string --enable-libgomp --enable-graphite --enable-mingw-wildcard --with-mpc=/d/Prog/winlibs32_stage/custombuilt --with-mpfr=/d/Prog/winlibs32_stage/custombuilt --with-gmp=/d/Prog/winlibs32_stage/custombuilt --with-isl=/d/Prog/winlibs32_stage/custombuilt --enable-install-libiberty --enable-__cxa_atexit --without-included-gettext --with-diagnostics-color=auto --with-libiconv --with-system-zlib --with-build-sysroot=/R/winlibs32_stage/gcc-11-20210228/mingw-w64 --enable-large-address-aware CFLAGS=-I/d/Prog/winlibs32_stage/custombuilt/include/libdl-win32 Note that I was able to build the 32-bit compiler once, but I had to disable fortran to work around this error. This is the second iteration where I try to build GCC 11-20210228 with the same version of GCC from the first iteration. Windows 64-bit builds work fine, so this error is limited to Windows 32-bit. Any idea what causes this?
[Bug c/97618] undefined reference to LC11 building for target MinGW-w64 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618 --- Comment #4 from Brecht Sanders --- Found a smaller project to reproduce the issue with: building BLAKE3 v0.3.7 from https://github.com/BLAKE3-team/BLAKE3 also has the issue when building with GCC11 for 32-bit MinGW-w64. Here I noticed that compiling with -O0 works around the problem, so the issue must be in the compiler optimization for i686.
[Bug c/97618] undefined reference to LC11 building for target MinGW-w64 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618 --- Comment #3 from Brecht Sanders --- Issue is till present in GCC 11 snapshot 20210131. When building GCC 11 with GCC 11 the error is still there when trying to build fortran. I also noticed the same error when using GCC 11 to build ccache 4.2. Any updates on this issue?
[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #27 from Brecht Sanders --- @Mikael Pettersson, should a similar patch be applied to gcc/config/i386/mingw-w64.h to fix this same issue in MinGW-w64?
[Bug target/98729] [11 Regression] GCC 11 MinGW Windows build doesn't generate working PE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729 --- Comment #11 from Brecht Sanders --- Created attachment 50113 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50113=edit objdump -h List of sections attached (created using `objdump -h`)
[Bug target/98729] [11 Regression] GCC 11 MinGW Windows build doesn't generate working PE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729 --- Comment #9 from Brecht Sanders --- The attached .exe will run on Windows after removing the section called `/20` from the PE file using: `strip conftest.exe --remove-section="/20"` I don't know what this section does, but I did notice it contains a reference to `cygwin.S`, which I didn't expect to see in a pure MinGW binary.
[Bug target/98729] [11 Regression] GCC 11 MinGW Windows build doesn't generate working PE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729 --- Comment #8 from Brecht Sanders --- Also, my win64 build uses SEH, not dwarf, so it doesn't look like dwarf is the issue. I also tried to build with `--enable-compressed-debug-sections=none`, but that fix the problem either.
[Bug target/98729] [11 Regression] GCC 11 MinGW Windows build doesn't generate working PE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729 --- Comment #7 from Brecht Sanders --- Adding flag `-gdwarf-4` to the above command still results in a file that won't execute, see attached file `conftest-gdwarf-4.exe`
[Bug target/98729] [11 Regression] GCC 11 MinGW Windows build doesn't generate working PE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729 --- Comment #6 from Brecht Sanders --- Created attachment 50004 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50004=edit test built with -gdwarf-4
[Bug target/98729] GCC 11 MinGW Windows build doesn't generate working PE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729 --- Comment #3 from Brecht Sanders --- Strange, I'm using the same binutils to build GCC 10.2.0 and have no issues there. Configuring the GCC build with `LDFLAGS_FOR_TARGET="-s"` works around this issue for now, but only for win64. For the win32 build libgfortran fails with `libgfortran/generated/matmul_c8.c:126: undefined reference to 'LC5'`
[Bug c/98729] GCC 11 MinGW Windows build doesn't generate working PE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729 --- Comment #1 from Brecht Sanders --- I have discovered that adding `-s` to the above build command or stripping the .exe file with `strip` does allow it to run. So probably something is messed up in the debugging symbols section.
[Bug c/98729] New: GCC 11 MinGW Windows build doesn't generate working PE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729
Bug ID: 98729
Summary: GCC 11 MinGW Windows build doesn't generate working PE
executables
Product: gcc
Version: 11.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 49994
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49994=edit
Invalid Windows .exe PE file
When I try to build GCC 11 for MinGW (using MinGW-w64 8.0.0) configure fails
(on both 32-bit and 64-bit) when it's trying to test if it can run a compiled
.exe file.
When I replicate this command with:
`echo "int main () { return 0; }" |
/R/winlibs64_stage/gcc-11-20210117/build_mingw/./gcc/xgcc
-B/R/winlibs64_stage/gcc-11-20210117/build_mingw/./gcc/
-L/R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/x86_64-w64-mingw32/lib
-L/R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/mingw/lib -isystem
/R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/x86_64-w64-mingw32/include
-isystem /R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/mingw/include
-B/R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/x86_64-w64-mingw32/bin/
-B/R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/x86_64-w64-mingw32/lib/
-isystem
/R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/x86_64-w64-mingw32/include
-isystem
/R/winlibs64_stage/inst_gcc-11-20210117/share/gcc/x86_64-w64-mingw32/sys-include
--sysroot=/R/winlibs64_stage/gcc-11-20210117/build_mingw/mingw-w64 -o
conftest.exe -g -O2 -xc -`
it builds `conftest.exe`, but running it (fro MSYS2 bash shell) with
`conftest.exe` fails with error `bash: ./conftest.exe: cannot execute binary
file: Exec format error`, or when I run it from Windows or Command prompt it
pops up a message saying `This app can't run on your PC`.
The command `file conftest.exe` does return `conftest.exe: PE32+ executable
(console) x86-64, for MS Windows`.
I have attached this file.
[Bug lto/98145] gcc with nvptx offloading on Windows: lto-wrapper can't find accel/nvptx-none/mkoffload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98145
--- Comment #3 from Brecht Sanders
---
Fixing gcc/config/nvptx/mkoffload.c got me one step further, but now the
parameters seem to be the issue:
lto1.exe: error: unrecognized command-line option '-mgomp'
lto1.exe: error: '-foffload-abi' option can be specified only for offload
compiler
mkoffload: fatal error:
D:\Prog\winlibs64-10.2.0-8.0.0\mingw64\bin/x86_64-w64-mingw32-accel-nvptx-none-gcc.exe
returned 1 exit status
compilation terminated.
lto-wrapper.exe: fatal error:
d:/prog/winlibs64-10.2.0-8.0.0/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/10.2.0//accel/nvptx-none/mkoffload.exe
returned 5 exit status
compilation terminated.
d:/prog/winlibs64-10.2.0-8.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status
The command line being run was:
g++ -Wall -O2 -g -fno-exceptions -fopenmp testomp.cpp kernelomp.o HybridOMP.o
-o testomp
from the Makefile in https://github.com/matthiasdiener/omptest/
The patches to get up to this point (which don't break other platforms) are:
patch -ulbf gcc/lto-wrapper.c << EOF
@@ -548,4 +548,10 @@
/* Parse STR, saving found tokens into PVALUES and return their number.
- Tokens are assumed to be delimited by ':'. If APPEND is non-null,
- append it to every token we find. */
+ Tokens are assumed to be delimited by ':' (or ';' on Windows).
+ If APPEND is non-null, append it to every token we find. */
+
+#ifdef _WIN32
+#define PATH_LIST_SEPARATOR ';'
+#else
+#define PATH_LIST_SEPARATOR ':'
+#endif
@@ -558,3 +564,3 @@
- curval = strchr (str, ':');
+ curval = strchr (str, PATH_LIST_SEPARATOR);
while (curval)
@@ -562,3 +568,3 @@
num++;
- curval = strchr (curval + 1, ':');
+ curval = strchr (curval + 1, PATH_LIST_SEPARATOR);
}
@@ -567,3 +573,3 @@
curval = str;
- nextval = strchr (curval, ':');
+ nextval = strchr (curval, PATH_LIST_SEPARATOR);
if (nextval == NULL)
@@ -581,3 +587,3 @@
curval = nextval + 1;
- nextval = strchr (curval, ':');
+ nextval = strchr (curval, PATH_LIST_SEPARATOR);
if (nextval == NULL)
@@ -816,2 +822,8 @@
+#ifdef _WIN32
+#define BIN_EXT ".exe"
+#else
+#define BIN_EXT ""
+#endif
+
static char *
@@ -827,6 +839,6 @@
char *suffix
-= XALLOCAVEC (char, sizeof ("/accel//mkoffload") + strlen (target));
+= XALLOCAVEC (char, sizeof ("/accel//mkoffload" BIN_EXT) + strlen
(target));
strcpy (suffix, "/accel/");
strcat (suffix, target);
- strcat (suffix, "/mkoffload");
+ strcat (suffix, "/mkoffload" BIN_EXT);
EOF
patch -ulbf gcc/config/nvptx/mkoffload.c << EOF
@@ -160,3 +160,10 @@
/* Parse STR, saving found tokens into PVALUES and return their number.
- Tokens are assumed to be delimited by ':'. */
+ Tokens are assumed to be delimited by ':' (or ';' on Windows). */
+
+#ifdef _WIN32
+#define PATH_LIST_SEPARATOR ';'
+#else
+#define PATH_LIST_SEPARATOR ':'
+#endif
+
static unsigned
@@ -168,3 +175,3 @@
- curval = strchr (str, ':');
+ curval = strchr (str, PATH_LIST_SEPARATOR);
while (curval)
@@ -172,3 +179,3 @@
num++;
- curval = strchr (curval + 1, ':');
+ curval = strchr (curval + 1, PATH_LIST_SEPARATOR);
}
@@ -177,3 +184,3 @@
curval = str;
- nextval = strchr (curval, ':');
+ nextval = strchr (curval, PATH_LIST_SEPARATOR);
if (nextval == NULL)
@@ -188,3 +195,3 @@
curval = nextval + 1;
- nextval = strchr (curval, ':');
+ nextval = strchr (curval, PATH_LIST_SEPARATOR);
if (nextval == NULL)
@@ -393,2 +400,8 @@
+#ifdef _WIN32
+#define BIN_EXT ".exe"
+#else
+#define BIN_EXT ""
+#endif
+
int
@@ -413,3 +426,3 @@
size_t len = (strlen (gcc_path) + 1
- + strlen (GCC_INSTALL_NAME)
+ + strlen (GCC_INSTALL_NAME BIN_EXT)
+ 1);
@@ -425,3 +438,3 @@
driver_used = sprintf (driver, "%s/", gcc_path);
- sprintf (driver + driver_used, "%s", GCC_INSTALL_NAME);
+ sprintf (driver + driver_used, "%s", GCC_INSTALL_NAME BIN_EXT);
@@ -442,5 +455,5 @@
{
- len = strlen (paths[i]) + 1 + strlen (GCC_INSTALL_NAME) + 1;
+ len = strlen (paths[i]) + 1 + strlen (GCC_INSTALL_NAME BIN_EXT) + 1;
driver = XRESIZEVEC (char, driver, len);
- sprintf (driver, "%s/%s", paths[i], GCC_INSTALL_NAME);
+ sprintf (driver, "%s/%s", paths[i], GCC_INSTALL_NAME BIN_EXT);
if (access_check (driver, X_OK) == 0)
@@ -457,3 +470,3 @@
"offload compiler %s not found (consider using %<-B%>)",
-GCC_INSTALL_NAME);
+GCC_INSTALL_NAME BIN_EXT);
EOF
[Bug lto/98145] gcc with nvptx offloading on Windows: lto-wrapper can't find accel/nvptx-none/mkoffload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98145
--- Comment #2 from Brecht Sanders
---
Did a bit more digging...
Seems COMPILER_PATH uses ';' as separator on Windows, not ':'.
So besides the .exe issue parse_env_var() also needs to separate the list by a
different separator.
Something like this:
# fix gcc/lto-wrapper.c (version >= 10.2.0)
patch -ulbf gcc/lto-wrapper.c << EOF
@@ -548,4 +548,10 @@
/* Parse STR, saving found tokens into PVALUES and return their number.
- Tokens are assumed to be delimited by ':'. If APPEND is non-null,
- append it to every token we find. */
+ Tokens are assumed to be delimited by ':' (or ';' on Windows).
+ If APPEND is non-null, append it to every token we find. */
+
+#ifdef _WIN32
+#define PATH_LIST_SEPARATOR ';'
+#else
+#define PATH_LIST_SEPARATOR ':'
+#endif
@@ -558,3 +564,3 @@
- curval = strchr (str, ':');
+ curval = strchr (str, PATH_LIST_SEPARATOR);
while (curval)
@@ -562,3 +568,3 @@
num++;
- curval = strchr (curval + 1, ':');
+ curval = strchr (curval + 1, PATH_LIST_SEPARATOR);
}
@@ -567,3 +573,3 @@
curval = str;
- nextval = strchr (curval, ':');
+ nextval = strchr (curval, PATH_LIST_SEPARATOR);
if (nextval == NULL)
@@ -581,3 +587,3 @@
curval = nextval + 1;
- nextval = strchr (curval, ':');
+ nextval = strchr (curval, PATH_LIST_SEPARATOR);
if (nextval == NULL)
@@ -827,6 +833,6 @@
char *suffix
-= XALLOCAVEC (char, sizeof ("/accel//mkoffload") + strlen (target));
+= XALLOCAVEC (char, sizeof ("/accel//mkoffload.exe") + strlen (target));
strcpy (suffix, "/accel/");
strcat (suffix, target);
- strcat (suffix, "/mkoffload");
+ strcat (suffix, "/mkoffload.exe");
EOF
But still not there yet. Now my test results in:
mkoffload: fatal error: offload compiler
x86_64-w64-mingw32-accel-nvptx-none-gcc not found (consider using '-B')
compilation terminated.
lto-wrapper.exe: fatal error:
d:/prog/winlibs64-10.2.0-8.0.0/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/10.2.0//accel/nvptx-none/mkoffload.exe
returned 1 exit status
compilation terminated.
d:/prog/winlibs64-10.2.0-8.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
error: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status
So probably mkoffload needs similar fixes...
[Bug c/98145] On Windows .exe extension is missing when searching/calling mkoffload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98145 --- Comment #1 from Brecht Sanders --- Closer investigation shows the issue probably not (or not only) cause by the .exe extension: This is the error: lto-wrapper.exe: fatal error: could not find accel/nvptx-none/mkoffload.exe in d:/prog/winlibs32-10.2.0-8.0.0/mingw32/bin/../libexec/gcc/i686-w64-mingw32/10.2.0/;d:/prog/winlibs32-10.2.0-8.0.0/mingw32/bin/../libexec/gcc/;d:/prog/winlibs32-10.2.0-8.0.0/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/ (consider using '-B') d:/prog/winlibs32-10.2.0-8.0.0/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/ld.exe: error: lto-wrapper failed collect2.exe: error: ld returned 1 exit status But the file does exist: ls -l 'd:/prog/winlibs32-10.2.0-8.0.0/mingw32/bin/../libexec/gcc/i686-w64-mingw32/10.2.0/accel/nvptx-none/mkoffload.exe' -rwxr-xr-x 1 brecht None 609294 Dec 4 17:14 d:/prog/winlibs32-10.2.0-8.0.0/mingw32/bin/../libexec/gcc/i686-w64-mingw32/10.2.0/accel/nvptx-none/mkoffload.exe So the question remains: why is lto-wrapper not able to find the file that is obviously there where it's looking?
[Bug c/98145] New: On Windows .exe extension is missing when searching/calling mkoffload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98145
Bug ID: 98145
Summary: On Windows .exe extension is missing when
searching/calling mkoffload
Product: gcc
Version: 10.2.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: ---
I was trying to get nvptx offloading to work on Windows/MinGW-w64, and got the
following output when testing the resulting build:
lto-wrapper.exe: fatal error: could not find accel/nvptx-none/mkoffload in
d:/prog/winlibs64-10.2.0-8.0.0/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/10.2.0/;d:/prog/winlibs64-10.2.0-8.0.0/mingw64/bin/../libexec/gcc/;d:/prog/winlibs64-10.2.0-8.0.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/
(consider using '-B')
compilation terminated.
It looks to me like gcc/lto-wrapper.c needs to be fixed so it looks for
mkoffload.exe instead of just mkoffload on Windows.
Probably something like this but with some additional checks to only add the
.exe on the Windows platform:
patch -ulbf gcc/lto-wrapper.c << EOF
@@ -827,6 +827,6 @@
char *suffix
-= XALLOCAVEC (char, sizeof ("/accel//mkoffload") + strlen (target));
+= XALLOCAVEC (char, sizeof ("/accel//mkoffload.exe") + strlen (target));
strcpy (suffix, "/accel/");
strcat (suffix, target);
- strcat (suffix, "/mkoffload");
+ strcat (suffix, "/mkoffload.exe");
EOF
[Bug c/97618] undefined reference to LC11 building for target MinGW-w64 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618 --- Comment #2 from Brecht Sanders --- To build mpfr wich fails with: build_mingw\i686-w64-mingw32\libgcc/../../../libgcc/config/libbid/bid128_div.c:1523: undefined reference to `LC4' I figured out that the symbol LC4 is defined in libgcc.a, so I was able to build mpfr by running: make LIBS="-Wl,--as-needed -lgmp -lgcc" It appears that in this case the GCC 11 linker doesn't automatically link with libgcc.
[Bug c/97618] undefined reference to LC11 building for target MinGW-w64 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618 --- Comment #1 from Brecht Sanders --- I see a similar issue when building mpfr with the resulting compiler, but here the error is: build_mingw\i686-w64-mingw32\libgcc/../../../libgcc/config/libbid/bid128_div.c:616: undefined reference to `LC4' and replacing -O3 with -O2 or -Os didn't work.
[Bug c/97618] New: undefined reference to LC11 building for target MinGW-w64 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618 Bug ID: 97618 Summary: undefined reference to LC11 building for target MinGW-w64 32-bit Product: gcc Version: 11.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: --- When building GCC11 with MinGW-w64 32-bit it fails in the Fortran language with undefined references to LC symbols. Continuing to build without Fortran works. However when using the resulting compuler the same error reappears when building other libraries like libffi and boost. The output of boost is this: gcc.link.dll.mingw build_win\boost\bin.v2\libs\log\build\gcc-11.0.0\release\visibility-hidden\libboost_log-x32.dll.a d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe: build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0x3b9): undefined reference to `LC10' d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe: build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0x3c9): undefined reference to `LC11' d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe: build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0xce6): undefined reference to `LC10' d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe: build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0xcee): undefined reference to `LC11' d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe: build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0x19c6): undefined reference to `LC10' d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe: build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0x19ce): undefined reference to `LC11' d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe: build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0x2740): undefined reference to `LC10' d:/prog/winlibs32_stage/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe: build_win/boost/bin.v2/libs/log/build/gcc-11.0.0/release/visibility-hidden/dump_avx2.o:dump_avx2.cpp:(.text+0x2750): undefined reference to `LC11' collect2.exe: error: ld returned 1 exit status With libffi I noticed that when I replace -O3 with -O2 in each Makefile it does actually build. So it appears the issue is triggered by -O3 optimizations for MinGW Windows 32-bit builds.
[Bug analyzer/97614] New: MinGW-w64 pointer to long conversion loses precision error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97614 Bug ID: 97614 Summary: MinGW-w64 pointer to long conversion loses precision error Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: brechtsanders at users dot sourceforge.net Target Milestone: --- When compiling GCC 11-20201025 with MinGW-w64 I got the following error: ../../gcc/analyzer/store.h: In member function 'hashval_t ana::symbolic_binding::hash() const': ../../gcc/analyzer/store.h:272:41: error: cast from 'const ana::region*' to 'long int' loses precision [-fpermissive] 272 | return (binding_key::impl_hash () ^ (long)m_region); | ^~ This is typically caused by the false assumption that pointer and long have the same size, which is not true on Windows/MinGW. Usually the solution is to cast to something like intptr_t instead of long.
[Bug libstdc++/97484] typedef conflict for "byte" in GCC11 for MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97484 Brecht Sanders changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Brecht Sanders --- Yes, you're right, when setting CXXFLAGS="-std=c++17" and building with GCC 10 Ninja also fails to build. I have opened a ticket with Ninja for this, see: https://github.com/ninja-build/ninja/issues/1861
[Bug libstdc++/97484] typedef conflict for "byte" in GCC11 for MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97484 --- Comment #3 from Brecht Sanders --- MinGW is pure C, so it doesn't use: using namespace std; But I do see Ninja doing this before including windows.h. However GCC 10 and older have no issue with this. What changed in GCC 11 to cause the issue?
[Bug c++/97484] New: typedef conflict for "byte" in GCC11 for MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97484 Bug ID: 97484 Summary: typedef conflict for "byte" in GCC11 for MinGW-w64 Product: gcc Version: 11.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: --- I just built GCC11 snapshot 20201011 for the MinGW-w64 platform and noticed that some things won't build with it because "byte" now has conflicting definitions. Windows seems to already define this in rpcndr.h, which is included from windows.h. But it's also defined in C++' cpp_type_traits. The errors below are from an attempt to compile Ninja with GCC11 snapshot 20201011. These issues were not present with GCC 11 or lower. In file included from d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\wtypes.h:8, from d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\winscard.h:10, from d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\windows.h:97, from .\src\disk_interface.cc:27: d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\rpcndr.h:64:11: error: reference to 'byte' is ambiguous 64 | typedef byte cs_byte; | ^~~~ In file included from d:\prog\winlibs32_stage\mingw32\include\c++\11.0.0\bits\stl_algobase.h:61, from d:\prog\winlibs32_stage\mingw32\include\c++\11.0.0\bits\stl_tree.h:63, from d:\prog\winlibs32_stage\mingw32\include\c++\11.0.0\map:60, from .\src\disk_interface.h:18, from .\src\disk_interface.cc:15: d:\prog\winlibs32_stage\mingw32\include\c++\11.0.0\bits\cpp_type_traits.h:404:30: note: candidates are: 'enum class std::byte' 404 | enum class byte : unsigned char; | ^~~~ In file included from d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\wtypes.h:8, from d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\winscard.h:10, from d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\windows.h:97, from .\src\disk_interface.cc:27: d:\prog\winlibs32_stage\mingw32\i686-w64-mingw32\include\rpcndr.h:63:25: note: 'typedef unsigned char byte' 63 | typedef unsigned char byte; | ^~~~
