https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
--- Comment #18 from Brecht Sanders ---
Thanks for you work on this.
My goal is to eventually have native binutils+GCC on Windows ARM64.
I tried using sources from:
https://github.com/Windows-on-ARM-Experiments/binutils-woarm64
https://github.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
--- Comment #16 from Brecht Sanders ---
What is the current status of GCC for aarch64-w64-mingw32 ?
When can I expect a snapshot version of GCC 15 to build for this platform?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #17 from Brecht Sanders ---
These undefined references seem to exist in libphobos/src/.libs/libgphobos.a
Is d21.exe somehow not linking against that library by mistake?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #16 from Brecht Sanders ---
Whatever I try, I always get stuck on building d21.exe.
make: Entering directory
'/home/brecht/build-gcc/build_stage2-gcc-x86_64-w64-mingw32/gcc'
x86_64-w64-mingw32-gdc -lstdc++ -g -DIN_GCC-fno-ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104654
--- Comment #1 from Brecht Sanders
---
This problem is still present in GCC snapshot 15-20250209.
Any news on how to fix libphobos/libdruntime/gcc/gthread.d for building with
--enable-threads=posix ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #15 from Brecht Sanders ---
So what is needed to be able to use gdc to build a simple "Hello world" program
for Windows (x86_64-w64-mingw32)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #13 from Brecht Sanders ---
I understand that would give me a gdc with runtime and no libphobos.
What is needed to make that usable as a compiler?
Do I need to build libphobos spearately or from a different source?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #11 from Brecht Sanders ---
Apparently MinGW-w64 dosn't like extern char** environ;
To avoid this issue for now I commented out the following in gcc/cp/module.cc:
extern char **environ;
while (const char *var = environ[vars.leng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #10 from Brecht Sanders ---
Looks like _pgmptr was superseded by _get_pgmptr().
So I tried this quick and dirty fix to get past the issue:
patch -ulbf libbacktrace/fileline.c << EOF
@@ -262,3 +262,7 @@
to the wine binar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #9 from Brecht Sanders
---
Same thing happens with --enable-languages=c,c++,fortran,d
What is causing the error: "undefined reference to `__imp___p__pgmptr'" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #8 from Brecht Sanders
---
Yes, that was with --languages=d only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #6 from Brecht Sanders
---
Sorry it took me a while to get the hang of building a canadian cross from
Linux.
When building gdc for Windows 64-bit I get the following:
make[2]: Entering directory
'/home/brecht/build-gcc/build_stage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #5 from Brecht Sanders
---
Yes, it builds find with --with-libphobos-druntime-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118495
--- Comment #3 from Brecht Sanders
---
I was just trying to build GCC 12,13,14 with D+libphobos using GCC11.
No success.
GCC12:
libtool: compile: /R/winlibs_gcc1564/gcc-12.4.0/build_mingw/./gcc/gdc
-B/R/winlibs_gcc1564/gcc-12.4.0/build_min
: d
Assignee: ibuclaw at gdcproject dot org
Reporter: brechtsanders at users dot sourceforge.net
Target Milestone: ---
I have been attempting to nateveliy build the gdc D compiler on Windows
MinGW-w64.
The last build with where D language and libphobos didn't fail was GCC1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118244
Brecht Sanders changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118283
--- Comment #4 from Brecht Sanders
---
Thanks for clarifying.
So it seems this is by design and there is nothing to fix in GCC.
Unfortunately that means a lot of packages will need to fix their source if
they still want them to build using th
Assignee: unassigned at gcc dot gnu.org
Reporter: brechtsanders at users dot sourceforge.net
Target Milestone: ---
I was able to compile GCC 15 (20241229 snapshot) against MinGW-w64.
So I tried building a lot of open source projects with it.
Several projects fail to build and a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118244
--- Comment #7 from Brecht Sanders
---
This somehow did allow the build to proceed:
make -Cbuild_mingw/$RUNPLATFORM/libstdc++-v3 LDFLAGS="-L$PWD/build_mingw/gcc
-lcommon"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118244
--- Comment #6 from Brecht Sanders
---
I tried building without '-D__USE_MINGW_ANSI_STDIO=0' and I still get the same
undefined references.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118244
--- Comment #5 from Brecht Sanders
---
The purpose of CFLAGS=-D__USE_MINGW_ANSI_STDIO=0 was to speed up console
output, because MinGW's own printf is quite slow.
I only want to speed up console output of GCC tools. Is there a better place to
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118244
--- Comment #2 from Brecht Sanders
---
../configure --prefix=/R/winlibs14.2.0msvcrt64/inst_gcc-14.2.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-p
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: brechtsanders at users dot sourceforge.net
Target Milestone: ---
I'm trying a native Windows MinGW-w64 build of GCC15 (snapshot 15-20241229) and
I get errors when building libstdc++-v3:
make[5]: Entering director
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: brechtsanders at users dot sourceforge.net
Target Milestone: ---
When trying to build snapshot 15-20241222 on Windows / MinGW-w64 the build
fails on gcc/lto
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312
--- Comment #6 from Brecht Sanders
---
You're right. Sorry I missed that.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312
Brecht Sanders changed:
What|Removed |Added
CC||brechtsanders at users dot
sourcef
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 s
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 --
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 nat
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://github.com/msys2/MINGW-packages/bl
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
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://github.com/brechtsanders/winlibs_ming
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://github.com/msys2/
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 of
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
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&action=edit
Process Monitor when running `gcc -print-prog-name=cc1`
Process Monitor when running `gcc -print-prog-name=c
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
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&action=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
somepath/libexec/gcc/x86_64-w64-ming
oduct: 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
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 2f
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
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
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
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
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 l
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 'R:\winlibs32_stage\_TMP_\ccYJWYIt.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 --prefix=/R/winlibs64_stage/inst_
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
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&action=edit
libatomic/config.log
When doing a Windows native build of
: 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.
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
: 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=50
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
Howeve
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&action=edit
i686-w64-mingw32/libgomp/config.log
When building
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, w
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 CppRu
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/winlib
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
Status|UNCONFIRME
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&action=edit
gcc -v
ormal
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&action=edit
make
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 c
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
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&action=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 co
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&action=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 win3
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.
ormal
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&action=edit
Invalid Win
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 t
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/winlib
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
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 `LC4'
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
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
1 - 100 of 106 matches
Mail list logo
