https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461
--- Comment #8 from Daniel Starke ---
This bug was fixes in mingw-w64. The bug fix is included since versions 8.0.1.
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461
--- Comment #6 from Daniel Starke ---
Thank you for the suggestion, however, I am not involved in the mingw-w64
project. Furthermore, the fact that this regression remains against all
versions of mingw-w64 known to date does not change.
It is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461
--- Comment #4 from Daniel Starke ---
Created attachment 50772
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50772=edit
rdtsc.c
Please find attached the mingw-w64 file.
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
GCC 11.1.0 build for mingw-w64 is broken now. Up to 10.3.0 the following was
used in gcc/config/i386/ia32intrin.h
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
GCC 11.1.0 fails to build with C++ under MinGW due to unsupported open() flags
S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95253
--- Comment #6 from Daniel Starke ---
That is what I did as workaround for me, but I am not sure how this affacts
other targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95253
Daniel Starke changed:
What|Removed |Added
Component|target |preprocessor
--- Comment #3 from Daniel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95253
--- Comment #2 from Daniel Starke ---
Minimal test case on MSys/MinGW:
echo '#include ' | gcc -MD -MF - -fsyntax-only -x c -
Result with gcc 9.3.0:
-: \
e:\msys\mingw64_9.3.0\lib\gcc\x86_64-w64-mingw32\9.3.0\include\stddef.h \
[...]
Result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95253
--- Comment #1 from Daniel Starke ---
Edit: I meant colon character, not column operator.
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
Previously in gcc 9.3.0, escaping of the dependency file output still worked
well. Now I get a dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015
Daniel Starke changed:
What|Removed |Added
Known to work||8.3.0
--- Comment #10 from Daniel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88896
--- Comment #3 from Daniel Starke ---
Never mind my question.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88896
--- Comment #2 from Daniel Starke ---
You are right. So you are saying that the compiler actually checks all cases of
the loop?
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
Created attachment 45451
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45451=edit
test case and asm output
Using built-in sp
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
Created attachment 44690
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44690=edit
test case
Using GCC version 8.2.0 in mingw-w64 compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015
--- Comment #5 from Daniel Starke ---
I tried the version 8 branch snapshot from 2018-08-24 but the issue still
remains.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015
--- Comment #4 from Daniel Starke ---
Sure, but it will take some days as I am currently reducing a testcase for
another bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015
--- Comment #2 from Daniel Starke ---
I am not quite sure how to do this in this case. GCC terminates without an
error but the resulting application misbehaves since GCC 8.1.0. That means the
assembly output is wrong. Any idea on how to make a
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
Starting with GCC 8.1.0 I encounter wrong code generations when using template
heavy C++ code with Boost Spirit. Using Boost 1.66
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86048
--- Comment #1 from Daniel Starke ---
The error does not occur if I pass -fno-reorder-blocks-and-partition.
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
Created attachment 44232
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44232=edit
pre-processed source f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Daniel Starke changed:
What|Removed |Added
Known to work|5.3.0 |
--- Comment #16 from Daniel Starke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #12 from Daniel Starke ---
I am not an expert on this field but your build does not use platform tls
support as mine is supposed to do. Furthermore, I was building all under
Windows. The only difference during the build process was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #9 from Daniel Starke ---
This was a native build.
I have added the GCC build in question to
https://sourceforge.net/projects/gcc-win64/files/7.1.0/gcc-7.1.0-debug-broken-tls.7z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #7 from Daniel Starke ---
Error report from Dr.Memory:
Error #1: UNADDRESSABLE ACCESS: reading 0x-0x0008 8
byte(s)
# 0 gomp_resolve_num_threads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #2 from Daniel Starke ---
True, I have rebuild GCC without --enable-tls enabled and the null pointer
access is gone. So I guess there is still no TLS support for mingw-w64 (even
though Windows supports it as far as I know).
: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
CC: jakub at gcc dot gnu.org
Target Milestone: ---
GCC 7.1.0 compiled OpenMP applications fail with invalid memory access to
address 0.
Used configuration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78535
--- Comment #3 from Daniel Starke ---
Created attachment 40176
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40176=edit
-fdump-ipa-devirt-details output
Requested -fdump-ipa-devirt-details output.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78535
--- Comment #1 from Daniel Starke ---
Comparing the outputs created with -fdump-tree-all enabled for both tested
command-line combinations hints that -flto -fdevirtualize fails when one of the
following passes is enabled via -O1:
- nothrow
-
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
Using GCC:
Target: x86_64-w64-mingw32
Configured with: ../../src/gcc-6.2.0/configure --host=x86_64-w64-mingw32
--enable-languages=c,c++ --enable-seh-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70378
--- Comment #1 from Daniel Starke ---
No warning was observed when using g++ instead of gcc.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
Tested with GCC 4.4.3 and 5.3.0 whereas 5.3.0 was configured as
Configured with: ../../src/gcc-5.3.0/configure --host=x86_64-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69284
--- Comment #6 from Daniel Starke ---
(In reply to katayama.hirofumi...@gmail.com from comment #4)
> Hello, Andrew Pinski.
> Where is ld bug track?
See https://sourceware.org/bugzilla/show_bug.cgi?id=19480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69394
--- Comment #4 from Daniel Starke ---
I see, but the output of the same GCC version should be the same regardless the
host if the target is the same, right?
I used the same source tree to build GCC 5.3.0 for x86_64-linux-gnu and for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69394
--- Comment #2 from Daniel Starke ---
I have tested the same with gcc 4.9.3 to make clear whether this is a
regression or not. Sadly I was not able to build the libstdc++ with -flto.
Compiling the same program as before did not result in a ICE
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
Created attachment 37410
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37410=edit
ICE backtrace
Configured with: ../../src/gcc-5.3.0/configure --enable-languages=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69284
--- Comment #1 from Daniel Starke ---
I have tried a couple of things to find the cause of this bug.
- using -O1 instead of -O3 when building GCC
- using -O2 instead of -O3 when building GCC
- using -fno-lto when building GCC
- using the
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
Using GCC 5.3 compiled as
../../src/gcc-5.3.0/configure --enable-languages=c,c++ --enable-seh-exceptions
--enable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65995
Daniel Starke daniel.f.starke at freenet dot de changed:
What|Removed |Added
Known to fail||5.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65867
--- Comment #4 from Daniel Starke daniel.f.starke at freenet dot de ---
I have already sent a patch to the ML.
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01539.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65995
--- Comment #4 from Daniel Starke daniel.f.starke at freenet dot de ---
I was able to build r222810 without bootstrap. However, the result remains the
same. I am still getting the following error when linking all together:
lto1.exe: internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65995
--- Comment #3 from Daniel Starke daniel.f.starke at freenet dot de ---
I have yet to bootstrap the current trunk (r222810). It currently fails with
/usr/new-gcc/bin32/./prev-gcc/xg++ -B/usr/new-gcc/bin32/./prev-gcc/
-B/mingw/mingw32/bin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65995
--- Comment #2 from Daniel Starke daniel.f.starke at freenet dot de ---
I already applied the open() patch listed there so this is definitively a
different bug. I will try again with the current trunk hopefully within this
week.
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Target Milestone: ---
Using GCC 5.1.0 compiled as:
COLLECT_GCC=E:\msys\mingw64-64\bin\g++.exe
COLLECT_LTO_WRAPPER=e:/msys/mingw64-64/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.0/lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
Daniel Starke daniel.f.starke at freenet dot de changed:
What|Removed |Added
CC
: trivial
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Created attachment 35392
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35392action=edit
patch
Bootstrapping gcc 5.1 with ming32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60968
--- Comment #5 from Daniel Starke daniel.f.starke at freenet dot de ---
Removing --disable-sjlj-exceptions solved the problem.
I did not try the current 4.9.1 branch yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60968
--- Comment #6 from Daniel Starke daniel.f.starke at freenet dot de ---
I can confirm that the problem does not occur in r211103 of the 4.9 branch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60968
--- Comment #3 from Daniel Starke daniel.f.starke at freenet dot de ---
Created attachment 32720
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32720action=edit
gdb output with backtrace for -falign-functions
I have tried building GCC 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60968
--- Comment #2 from Daniel Starke daniel.f.starke at freenet dot de ---
I was able to locate the problem. The SIGSEG only occures when bootstrapping
GCC with -fomit-frame-pointer.
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.f.starke at freenet dot de
Created attachment 32684
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32684action=edit
gdb output with backtrace
Bootstrapping GCC 4.9 on Windows 7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60968
--- Comment #1 from Daniel Starke daniel.f.starke at freenet dot de ---
This bug does not occurs when bootstrapping GCC with -O0 -g2.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56357
--- Comment #4 from Daniel Starke daniel.f.starke at freenet dot de
2013-03-08 20:05:19 UTC ---
I tried the same configuration in a different mingw build environment for gcc.
The resulting gcc build worked fine and did not show
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56357
--- Comment #3 from Daniel Starke daniel.f.starke at freenet dot de
2013-02-26 08:02:13 UTC ---
I have currently no means to do so but I will try that as soon as possible.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56412
Bug #: 56412
Summary: [4.8 Regression] libtool: cygpath: command not found
for mingw32 host
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56412
--- Comment #1 from Daniel Starke daniel.f.starke at freenet dot de
2013-02-20 20:15:58 UTC ---
A patch of lto-plugin/configure could solve this issue for now if the patch of
libtool.m4 was too extensive for stage4.
--- gcc-4.8.0-r196092
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56412
--- Comment #2 from Daniel Starke daniel.f.starke at freenet dot de
2013-02-20 20:23:32 UTC ---
Sorry, here is the correct patch proposed.
--- gcc-4.8.0-r196092/lto-plugin/configure2013-02-15 22:11:56 +
+++ gcc-4.8.0-patch/lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52123
--- Comment #13 from Daniel Starke daniel.f.starke at freenet dot de
2013-02-16 12:41:42 UTC ---
I just tried out to bootstrap r196092 on mingw32. There is still one more cast
patch missing to make it work for that target.
diff -uart gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56357
Bug #: 56357
Summary: [4.8 Regression] missing symbol references for libgomp
when using -flto -fopenmp on mingw32
Classification: Unclassified
Product: gcc
Version:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56185
--- Comment #6 from Daniel Starke daniel.f.starke at freenet dot de
2013-02-13 21:08:40 UTC ---
This issue does not occur with checking enabled. See below a working
configuration.
COLLECT_GCC=D:\Programme\msys\mingw64\bin\x86_64-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52123
--- Comment #9 from Daniel Starke daniel.f.starke at freenet dot de
2013-02-06 17:04:21 UTC ---
This will probably not fix all problems with ada on mingw.
My last tests with 4.7.2 made me also need to patch this:
diff -uart gcc-4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56185
--- Comment #5 from Daniel Starke daniel.f.starke at freenet dot de
2013-02-07 06:43:35 UTC ---
The arithmetic exception is caught by gcc, thus not triggered in gdb. I tried a
couple of things with gdb but could not find the point at which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56185
Daniel Starke daniel.f.starke at freenet dot de changed:
What|Removed |Added
Known to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56185
--- Comment #1 from Daniel Starke daniel.f.starke at freenet dot de
2013-02-03 16:24:56 UTC ---
This issue does not appear with isl backend as in the configuration below.
However, I still need ppl to build gcc.
Using built-in specs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56185
Bug #: 56185
Summary: [4.7 Regression] ICE for Arithmetic exception with -O2
and -fgraphite
Classification: Unclassified
Product: gcc
Version: 4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48659
--- Comment #3 from Daniel Starke daniel.f.starke at freenet dot de
2013-01-28 11:53:14 UTC ---
I can confirm this bug for gcc 4.7.2 mingw64. The -mstackrealign command-line
flag can be used as workaround as described on
http
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #9 from Daniel Starke daniel.f.starke at freenet dot de
2012-09-24 16:55:33 UTC ---
The problem in autoconf was fixed with version 2.69. I suggest to update
AC_PREREQ within the configure.ac files to this version.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #10 from Daniel Starke daniel.f.starke at freenet dot de
2012-09-24 16:57:53 UTC ---
Here is the reference to the autoconf change:
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #7 from Daniel Starke daniel.f.starke at freenet dot de
2012-09-22 16:00:03 UTC ---
It seems to be partly a gcc autoconfig macro issue. Seeing the following in
gcc/acinclude.m4
dnl See if symbolic links work and if not, try
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #4 from Daniel Starke daniel.f.starke at freenet dot de
2012-04-26 18:06:54 UTC ---
Created attachment 27249
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27249
possible patch for gcc 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #5 from Daniel Starke daniel.f.starke at freenet dot de
2012-04-26 18:07:37 UTC ---
The mailinglist discussion covers only a part of the problem. I have attached a
possible patch for gcc 4.7.0 to highlight to problem.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
--- Comment #2 from Daniel Starke daniel.f.starke at freenet dot de
2012-04-05 16:14:19 UTC ---
(In reply to comment #1)
Please update this bug with respect to the mailing list discussion that took
place.
Can you please add a link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122
Bug #: 52122
Summary: [4.6.x/4.7] incorrect ln -s replacement for mingw like
targets in configure files
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52123
Bug #: 52123
Summary: [4.7] gcc bootstrap with ada fails on mingw target
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900
Bug #: 51900
Summary: [4.6 Regression] const variable initialization always
zero
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900
--- Comment #3 from Daniel Starke daniel.f.starke at freenet dot de
2012-01-19 11:52:27 UTC ---
[...]
COLLECT_GCC_OPTIONS='-static' '-O2' '-v' '-Q' '-o' 'a.o' '-c' '-mtune=i386'
'-march=i386'
[...]
GNU C (GCC) version 4.6.2 (mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900
--- Comment #5 from Daniel Starke daniel.f.starke at freenet dot de
2012-01-19 14:51:33 UTC ---
Compiling it with
gcc -static -fcommon -o main.o -c main.c
gcc -static -fcommon -o a.o -c a.c
gcc -static -o main.exe main.o a.o
results in
$ ./main
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51900
--- Comment #10 from Daniel Starke daniel.f.starke at freenet dot de
2012-01-20 07:41:10 UTC ---
I have tested the problem with the option switches -O0, -O1, -O2, -O3, -O4, -Os
and -Ofast. Only -O0 results in a 5, 6, 7 output. Turning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48233
Summary: [4.6] can't bootstrap with ada, java and go on mingw
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47814
--- Comment #2 from Daniel Starke daniel.f.starke at freenet dot de
2011-02-23 12:31:52 UTC ---
(In reply to comment #1)
lexer_line as well as the other problematic symbols are defined in
gengtype-lex.c:
nm build/gengtype-lex.o | egrep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47814
Summary: [4.6 Regression] Bootstrap fails on mingw32 by
undefined reference to 'lexer_line'
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47338
--- Comment #7 from Daniel Starke daniel.f.starke at freenet dot de
2011-01-20 18:51:53 UTC ---
As this patch also works with gcc 4.5.x I'd like to request this change for the
gcc 4.5 branch as well.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47338
Summary: [4.5 Regression][C++] cc1plus returns exist code 5
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47338
--- Comment #2 from daniel.f.starke at freenet dot de 2011-01-18 17:30:54 UTC
---
What do you mean by debug? I can't even compile it because cc1plus exists half
the way.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47338
--- Comment #4 from Daniel Starke daniel.f.starke at freenet dot de
2011-01-18 20:48:34 UTC ---
Here is the debugging output. I can attach the whole back-trace if needed.
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc
85 matches
Mail list logo
