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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99913
Brecht Sanders changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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?
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...
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
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
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 ?
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
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://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
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
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://gcc.gnu.org/bugzilla/show_bug.cgi?id=106728
Brecht Sanders changed:
What|Removed |Added
CC||brechtsanders at users dot
sourcef
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://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?
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
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
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
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`
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.
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"
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
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
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
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
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
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?
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
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401
Brecht Sanders changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
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
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
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
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
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:
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
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:
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).
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
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
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,
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
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91595
Brecht Sanders changed:
What|Removed |Added
CC||brechtsanders at users dot
sourcef
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. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97618
Brecht Sanders changed:
What|Removed |Added
Resolution|--- |DUPLICATE
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
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
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
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
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?
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`)
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
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.
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`
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
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
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.
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
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
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
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
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
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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97484
Brecht Sanders changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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
75 matches
Mail list logo
