[Bug c++/95749] New: std::filesystem::file_size returns wrong size for large files on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95749
Bug ID: 95749
Summary: std::filesystem::file_size returns wrong size for
large files on Windows
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reiter.christoph at gmail dot com
Target Milestone: ---
Downstream report: https://github.com/msys2/MINGW-packages/issues/6585
#include
#include
#include
#include
#include
int main(int argc, char** argv)
{
uint64_t std_filesystem_file_size;
uint64_t std_fstream_file_size;
std::filesystem::path sourceFile = std::filesystem::current_path() /
"example_3GiB.bin";
std::ofstream ofs(sourceFile);
ofs << "this is some text in the new file\n";
ofs.close();
std::filesystem::resize_file(sourceFile,3221225472);
std_filesystem_file_size = std::filesystem::file_size(sourceFile);
std::ifstream in(sourceFile.string(), std::ifstream::ate |
std::ifstream::binary);
std_fstream_file_size = in.tellg();
std::cout << "3 GiB file:" << std::endl;
std::cout << "std_filesystem_file_size: " << std_filesystem_file_size <<
std::endl;
std::cout << "std_fstream_file_size: " << std_fstream_file_size <<
std::endl;
return 0;
}
$ g++ -std=c++17 a.cpp
$ ./a.exe
3 GiB file:
std_filesystem_file_size: 18446744072635809792
std_fstream_file_size: 3221225472
The first value is wrong. My uneducated guess would be that
https://github.com/gcc-mirror/gcc/blob/41d6b10e96a1de98e90a7c0378437c3255814b16/libstdc%2B%2B-v3/src/filesystem/ops-common.h#L66
should use _wstat64() instead of _wstat and stat_type should be _stat64 instead
of _stat, otherwise things are limited to 32bit.
See
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=vs-2019
for details.
[Bug c/88424] New: Inserts newlines when preserving comments for a file using Windows newlines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88424
Bug ID: 88424
Summary: Inserts newlines when preserving comments for a file
using Windows newlines
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: reiter.christoph at gmail dot com
Target Milestone: ---
gcc --version
gcc (Debian 8.2.0-11) 8.2.0
When preprocessing a file which uses Windows newlines without discarding
comments (The -C option) then gcc inserts an extra newline after each line in
comments:
* Write the following to test.c and make sure it uses Windows newlines
/**
* Foo-
* bar-
* quux
*/
int main() {
return 0;
}
* Execute "gcc -C -E test.c"
3) Expected (this is what clang produces):
[...]
/**
* Foo-
* bar-
* quux
*/
int main() {
return 0;
}
* Actual:
/**
* Foo-
* bar-
* quux
*/
# 6 "test.c"
int main() {
return 0;
}
[Bug preprocessor/88424] Inserts newlines when preserving comments for a file using Windows newlines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88424 --- Comment #2 from Christoph Reiter --- For context, we use gcc in gobject-introspection where we parse metadata from the C comments and this breaks things when users on Windows have git set up to auto convert line endings: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/243
[Bug target/98341] [11/12 Regression] Ada bootstrap fails with Storage_Error stack overflow or erroneous memory access on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98341 Christoph Reiter changed: What|Removed |Added CC||reiter.christoph at gmail dot com --- Comment #12 from Christoph Reiter --- Note sure if this is related, but the 32bit Windows build of 11.1.0 fails in a similar way: gnat1.exe: warning: command-line option '-Wno-pedantic-ms-format' is valid for C/C++/ObjC/ObjC++ but not for Ada make[3]: *** [../../gcc-11.1.0/gcc/ada/gcc-interface/Make-lang.in:1052: ada/libgnat/a-except.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcc.pod gfortran.pod make[3]: Leaving directory '/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/gcc' make[2]: *** [Makefile:4833: all-stage2-gcc] Error 2 make[2]: Leaving directory '/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32' make[1]: *** [Makefile:26006: stage2-bubble] Error 2 make[1]: Leaving directory '/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32' make: *** [Makefile:1013: all] Error 2
[Bug ada/100486] New: Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 Bug ID: 100486 Summary: Ada build fails for 32bit Windows Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: reiter.christoph at gmail dot com Target Milestone: --- 10.3 works fine. Trying to build 11.1 results in the following error. I can try to debug this or try patches if someone can give me some hints on where to best start. Downstream issue: https://github.com/msys2/MINGW-packages/pull/8320 2021-05-08T11:34:54.1653856Z mkdir -p ada/libgnat/ 2021-05-08T11:34:54.2691662Z mkdir -p ada/libgnat/ 2021-05-08T11:34:54.2889496Z /C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc -B/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/ -B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include -B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include -fno-checking -c -g -O2 -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle -gnatpg -W -Wall -nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interface -I../../gcc-11.1.0/gcc/ada -I../../gcc-11.1.0/gcc/ada/gcc-interface -Iada/libgnat -I../../gcc-11.1.0/gcc/ada/libgnat ../../gcc-11.1.0/gcc/ada/libgnat/a-charac.ads -o ada/libgnat/a-charac.o 2021-05-08T11:34:54.3231740Z /C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc -B/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/ -B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include -B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include -fno-checking -c -g -O2 -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle -gnatpg -W -Wall -nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interface -I../../gcc-11.1.0/gcc/ada -I../../gcc-11.1.0/gcc/ada/gcc-interface -Iada/libgnat -I../../gcc-11.1.0/gcc/ada/libgnat ../../gcc-11.1.0/gcc/ada/libgnat/a-chlat1.ads -o ada/libgnat/a-chlat1.o 2021-05-08T11:34:54.3849423Z gnat1.exe: warning: command-line option '-Wno-pedantic-ms-format' is valid for C/C++/ObjC/ObjC++ but not for Ada 2021-05-08T11:34:54.4421984Z gnat1.exe: warning: command-line option '-Wno-pedantic-ms-format' is valid for C/C++/ObjC/ObjC++ but not for Ada 2021-05-08T11:34:54.8744980Z mkdir -p ada/libgnat/ 2021-05-08T11:34:54.8985212Z /C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc -B/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/ -B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include -B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include -fno-checking -c -g -O2 -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle -gnatpg -W -Wall -g -O1 -fno-inline \ 2021-05-08T11:34:54.9009139Z -nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interface -I../../gcc-11.1.0/gcc/ada -I../../gcc-11.1.0/gcc/ada/gcc-interface -Iada/libgnat -I../../gcc-11.1.0/gcc/ada/libgnat ../../gcc-11.1.0/gcc/ada/libgnat/a-except.adb -o ada/libgnat/a-except.o 2021-05-08T11:34:54.9369418Z /C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc -B/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/ -B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include -B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/i686-w64-mingw32/sys-include -fno-checking -c -g -O2 -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle -gnatpg -W -Wall -nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interface -I../../gcc-11.1.0/gcc/ada -I../../gcc-11.1.0/gcc/ada/gcc-interface -Iada/libgnat -I../../gcc-11.1.0/gcc/ada/libgnat ../../gcc-11.1.0/gcc/ada/libgnat/a-elchha.adb -o ada/libgnat/a-elchha.o 2021-05-08T11:34:55.0157169Z gnat1.exe: warning: command-line option '-Wno-pedantic-ms-format' is valid for C/C++/ObjC/ObjC++ but not for Ada 2021-05-08T11:34:55.1250712Z gnat1.exe: warning: command-line option '-Wno-pedantic-ms-format' is valid for C/C++/ObjC/ObjC++ but not for Ada 2021-05-08T11:34:55.2141773Z make[3]: *** [../../gcc-11.1.0/gcc/ada/gcc-interface/Make-lang.in:1052: ada/libgnat/a-except.o] Error 1 2021-05-08T11:34:55.2147024Z make[3]: *** Waiting for unfinished jobs 2021-05-08T11:34:55.4620283Z rm gcc.pod gfortran
[Bug web/107337] New: -march docs for nocona are missing CX16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107337 Bug ID: 107337 Summary: -march docs for nocona are missing CX16 Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: reiter.christoph at gmail dot com Target Milestone: --- On https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html nocona doesn't list CX16 despite it being enabled there. https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/gcc/common/config/i386/i386-common.c#L1742 thanks
[Bug web/107337] -march docs for nocona are missing CX16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107337 --- Comment #1 from Christoph Reiter --- Created attachment 53737 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53737&action=edit 0001-docs-nocona-has-CX16-enabled-by-default.patch
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #44 from Christoph Reiter --- Fore completeness: The "exceptions not working" problem now also crept into our v10.3 build with the last rebuild. Maybe some dependency change in the last two months, but no idea :/ https://github.com/msys2/MINGW-packages/issues/9771 So this isn't something new in v11
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #46 from Christoph Reiter --- (In reply to Eric Botcazou from comment #45) > > Fore completeness: The "exceptions not working" problem now also crept into > > our v10.3 build with the last rebuild. Maybe some dependency change in the > > last two months, but no idea :/ > > > > https://github.com/msys2/MINGW-packages/issues/9771 > > Can you confirm that this is with the same compiler sources as the previous > 10.3 version that works? Do you apply local changes to them? Yes, everything is checksummed in our build script. We apply various patches and backports, they are also checksummed: https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #48 from Christoph Reiter --- (In reply to Eric Botcazou from comment #47) > > Yes, everything is checksummed in our build script. We apply various patches > > and backports, they are also checksummed: > > https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD > > Did you change binutils, in particular the linker, in between? Yes, from 2.36.1 to 2.37, but I've already tried reverting that and it didn't help. I'm going to try older versions (of everything) though..
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #51 from Christoph Reiter --- (In reply to Eric Botcazou from comment #50) > > Yes, from 2.36.1 to 2.37, but I've already tried reverting that and it > > didn't help. I'm going to try older versions (of everything) though.. > > This could as well be a miscompilation of the linker. Can you upload ld.exe > somewhere so that I replace mine with it? If you happen to have an tool that supports extracting .tar.zst you could take the .exe from package directly: https://repo.msys2.org/mingw/mingw32/mingw-w64-i686-binutils-2.37-4-any.pkg.tar.zst
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #52 from Christoph Reiter --- Turns out this might be fallout from the last grep update, see https://github.com/msys2/MINGW-packages/issues/9771#issuecomment-945007372 Needs investigating..
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #72 from Christoph Reiter --- Works nicely now. Thanks everyone!
[Bug ada/105507] New: Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507 Bug ID: 105507 Summary: Ada build fails for 32bit Windows Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: reiter.christoph at gmail dot com Target Milestone: --- Downstream context: https://github.com/msys2/MINGW-packages/pull/11582 Building gcc 12.1.0 fails for 32bit Windows (64bit works): $ make [ -f stage_final ] || echo stage3 > stage_final make[1]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32' make[2]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32' make[3]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32' rm -f stage_current make[3]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32' make[2]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32' make[2]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32' make[3]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libiberty' make[4]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libiberty/testsuite' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libiberty/testsuite' make[3]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libiberty' make[3]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/lto-plugin' make all-am make[4]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/lto-plugin' make[4]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/lto-plugin' make[3]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/lto-plugin' make[3]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/intl' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/intl' make[3]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libiberty' make[4]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libiberty/testsuite' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libiberty/testsuite' make[3]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libiberty' make[3]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/fixincludes' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/fixincludes' make[3]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libcpp' test -f config.h || (rm -f stamp-h1 && make stamp-h1) make[3]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/build-i686-w64-mingw32/libcpp' make[3]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libbacktrace' make all-am make[4]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libbacktrace' true DO=all multi-do # make make[4]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libbacktrace' make[3]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libbacktrace' make[3]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libcpp' test -f config.h || (rm -f stamp-h1 && make stamp-h1) make[3]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libcpp' make[3]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libcody' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libcody' make[3]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libdecnumber' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/libdecnumber' make[3]: Entering directory '/home/user/M/mingw-w64-gcc/src/build-i686-w64-mingw32/gcc' mkdir -p ada/ gcc -c -g -gnatpg -gnatwns -W -Wall -I- -I. -Iada/generated -Iada -I../../gcc-12.1.0/gcc/ada ../.
[Bug ada/105507] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507 --- Comment #1 from Christoph Reiter --- I've bisected it now: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=76f9c7f44fffb0b03266730b137313fe79f1c99e 76f9c7f44fffb0b03266730b137313fe79f1c99e is the first bad commit commit 76f9c7f44fffb0b03266730b137313fe79f1c99e Author: Bob Duff Date: Wed Feb 3 05:31:16 2021 -0500 [Ada] Variable-sized node types 167 files changed, 18305 insertions(+), 43812 deletions(-)
[Bug ada/105507] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507 --- Comment #2 from Christoph Reiter --- Stack trace (I rebuilt the host gcc 11.3.0 with debug symbols and re-ran the failing command with "-wrapper gdb,--args"): Thread 1 received signal SIGSEGV, Segmentation fault. 0x7563bd90 in strlen () from C:\WINDOWS\SysWOW64\msvcrt.dll (gdb) bt #0 0x7563bd90 in strlen () from C:\WINDOWS\SysWOW64\msvcrt.dll #1 0x01731831 in libiberty_vprintf_buffer_size ( format=format@entry=0x1a3f865 "%s:%d", args=, args@entry=0x1367df64 "") at ../../gcc-11.3.0/libiberty/vprintf-support.c:105 #2 0x0173160a in xvasprintf ( format=format@entry=0x1a3f865 "%s:%d", args=args@entry=0x1367df64 "") at ../../gcc-11.3.0/libiberty/xvasprintf.c:57 #3 0x017312f7 in xasprintf ( fmt=0x1a3f865 "%s:%d") at ../../gcc-11.3.0/libiberty/xasprintf.c:47 #4 0x0041f315 in internal_error_function ( context=0x29d40c0 , msgid=0x1b2aebd "%s", ap=0x1367e0a0) at ../../gcc-11.3.0/gcc/ada/gcc-interface/misc.c:343 #5 0x016ab28d in diagnostic_report_diagnostic ( context=0x29d40c0 , diagnostic=, diagnostic@entry=0x1367e048) at ../../gcc-11.3.0/gcc/diagnostic.c:1225 #6 0x016ab7b7 in diagnostic_impl (richloc=0x1367e0a4, metadata=0x0, opt=-1, gmsgid=0x1b2aebd "%s", ap=0x1367e0a0, kind=DK_ICE) at ../../gcc-11.3.0/gcc/diagnostic.c:1406 #7 0x016abd98 in internal_error ( gmsgid=gmsgid@entry=0x1b2aebd "%s") at ../../gcc-11.3.0/gcc/diagnostic.c:1808 #8 0x00c53db1 in crash_signal (signo=22) at ../../gcc-11.3.0/gcc/toplev.c:327 #9 0x75608081 in raise () from C:\WINDOWS\SysWOW64\msvcrt.dll #10 0x0016 in ?? () #11 0x4925a812 in ?? () #12 0x1367e7b0 in ?? () #13 0x7560c5ab in msvcrt!abort () from C:\WINDOWS\SysWOW64\msvcrt.dll #14 0x0192e3d3 in uw_init_context_1 (context=0x0, context@entry=0x1367e730, outer_cfa=outer_cfa@entry=0x1367e7d0, outer_ra=0x16) at ../../../gcc-11.3.0/libgcc/unwind-dw2.c:1593 #15 0x0192e77f in _Unwind_RaiseException (exc=0x1619f880) at ../../../gcc-11.3.0/libgcc/unwind.inc:93 #16 0x00473f47 in ada.exceptions.exception_propagation.propagate_gcc_exception (gcc_exception=0x1619f880) at ../../gcc-11.3.0/gcc/ada/libgnat/a-exexpr.adb:597 #17 0x00473f96 in ada.exceptions.exception_propagation.propagate_exception ( excep=...) at ../../gcc-11.3.0/gcc/ada/libgnat/a-exexpr.adb:628 #18 0x00474414 in ada.exceptions.complete_and_propagate_occurrence ( x=x@entry=0x1619f8b0) at ../../gcc-11.3.0/gcc/ada/libgnat/a-except.adb:924 #19 0x00474447 in <__gnat_raise_exception> ( e=e@entry=0x1a31698 , message=...) at ../../gcc-11.3.0/gcc/ada/libgnat/a-except.adb:960 #20 0x0068e352 in sem_ch13.build_discrete_static_predicate.stat_pred ( typ=32975) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:9368 #21 0x0068fa75 in sem_ch13.build_discrete_static_predicate.get_rlist ( exp=) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:9129 #22 0x0068f922 in sem_ch13.build_discrete_static_predicate.get_rlist ( exp=203158) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:9015 #23 0x00693b59 in sem_ch13.build_discrete_static_predicate (typ=33050, expr=203158, nam=-399989278) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:9409 #24 0x00696f66 in sem_ch13.build_predicate_functions (typ=typ@entry=33050, n=n@entry=203112) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:10370 #25 0x006a59b2 in sem_ch13.freeze_entity_checks (n=203112) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:12728 #26 0x006a5ab5 in sem_ch13.analyze_freeze_entity (n=n@entry=203112) at ../../gcc-11.3.0/gcc/ada/sem_ch13.adb:8155 #27 0x0064416a in sem.analyze (n=n@entry=203112) at ../../gcc-11.3.0/gcc/ada/sem.adb:264 #28 0x00644d68 in sem.insert_list_after_and_analyze (n=203068, l=-99976824) at ../../gcc-11.3.0/gcc/ada/sem.adb:1254 #29 0x005b490f in freeze.freeze_all.freeze_all_ent.process_flist () at ../../gcc-11.3.0/gcc/ada/freeze.adb:1852 #30 0x005bf0f5 in freeze.freeze_all.freeze_all_ent (after=36978, from=32525) at ../../gcc-11.3.0/gcc/ada/freeze.adb:1940 #31 freeze.freeze_all (from=32525, after=36978) at ../../gcc-11.3.0/gcc/ada/freeze.adb:2020 #32 0x006ad855 in sem_ch3.analyze_declarations (l=, l@entry=-6744) at ../../gcc-11.3.0/gcc/ada/sem_ch3.adb:2837 #33 0x006fa1d7 in sem_ch7.analyze_package_specification (n=n@entry=32524) at ../../gcc-11.3.0/gcc/ada/sem_ch7.adb:1738 #34 0x006442f7 in sem.analyze (n=32524) at ../../gcc-11.3.0/gcc/ada/sem.adb:459 #35 0x006f978c in sem_ch7.analyze_package_declaration (n=n@entry=37004) at ../../gcc-11.3.0/gcc/ada/sem_ch7.adb:1210 #36 0x00643e5e in sem.analyze (n=n@entry=37004) at ../../gcc-11.3.0/gcc/ada/sem.adb:450 #37 0x0066c17a in sem_ch10.analyze_compilation_unit (n=32501) at ../../gcc-11.3.0/gcc/ada/sem_ch10.adb:913 #38 0x00644102 in sem.analyze (n=n@entry=32501) at ../../gcc-11.3.0/gcc/ada/sem.adb:180 #39 0x006454b1 in sem.semantics.do_analyze () at ../../gcc-11.3.0/gcc/ada/sem.adb:1421 #40 sem.semantics (comp_unit=32501)
[Bug ada/105507] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507 --- Comment #4 from Christoph Reiter --- I see, thanks for having a look :) We do have some open bugs re broken exception handling with mingw32, like https://github.com/msys2/MINGW-packages/issues/9289#issuecomment-945306860 Sadly no one stepped up to look into that. Do you think this could be related?
[Bug ada/105507] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507 --- Comment #7 from Christoph Reiter --- We currently link: shared: gmp, winpthread, zlib, zstd static: mpc, mpfr, isl Not for any particular gcc related reason I think, some dependent packages have static/shared builds, some don't.
[Bug ada/105507] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507 --- Comment #9 from Christoph Reiter --- (In reply to Eric Botcazou from comment #8) > > We currently link: > > > > shared: gmp, winpthread, zlib, zstd > > static: mpc, mpfr, isl > > > > Not for any particular gcc related reason I think, some dependent packages > > have static/shared builds, some don't. > > Why didn't I think of that for PR ada/100486? Sorry, I didn't know this was a problem :) I'm not quite sure how I ended up maintaining this downstream... but here we are. > So the fix should have been > to add -shared-libgcc to GCC_LINKERFLAGS in > gcc/ada/gcc-interface/Make-lang.in: > > # Strip -Werror during linking for the LTO bootstrap > GCC_LINKERFLAGS = $(filter-out -Werror, $(ALL_LINKERFLAGS)) -shared-libgcc > > in your setup since you link gnat1 with shared libraries. This should > override the -static-libgcc in ALL_LINKERFLAGS inherited from toplevel. > > So you need to to it 1) for GCC 11: rebuild it and reinstall it 2) for GCC > 12: build it with the patched GCC 11. Note that this means that GCC 11 is > currently not fully functional anyway. Thanks for the detailed instructions. I'll give that a try. I'm wondering if there are any downsides to just removing "-static-libgcc" from both "--with-stage1-ldflags" and "--with-boot-ldflags". Or is only ada using exceptions in GCC? Or should we try linking everything statically to avoid this alltogether?
[Bug ada/105507] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105507 Christoph Reiter changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #11 from Christoph Reiter --- I went with --with-boot-ldflags="-static-libstdc++" and --with-stage1-ldflags="-static-libstdc++" now, and everything works nicely. Thanks for your help and insight. I'll document the dwarf-2 limitation downstream, so this hopefully wont happen again.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #73 from Christoph Reiter --- In a similar bug 105507 we figured out that the MSYS2 build was broken because it was linking libgcc both statically and dynamically via dependencies, and that breaks exceptions with dwarf-2. So in theory the above patch could be reverted. I can try building with it being reverted to confirm, if wanted.
[Bug libgomp/105745] New: Conditional OpenMP directive fails with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745
Bug ID: 105745
Summary: Conditional OpenMP directive fails with GCC 12
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: reiter.christoph at gmail dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Downstream issue: https://github.com/msys2/MINGW-packages/issues/11729
The following example crashes with GCC 12.1.0, but works fine with GCC 11.3.0:
// g++ -fopenmp -o broken.exe broken.c; ./broken.exe; echo $?
int main() {
#pragma omp parallel for if (0)
for (int idx = 0; idx < 0; ++idx) { }
return 0;
}
* Removing the "if (0)" condition makes it work again
* Replacing libgomp-1.dll with the one from GCC 11.3 also makes things work
again.
* Another example that crashes is "#pragma omp for schedule(dynamic)"
This is on 32/64 bit Windows.
[Bug target/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745 --- Comment #2 from Christoph Reiter --- For "#pragma omp parallel for if (0)": #0 0x7ffacdeac6b3 in ntdll!RtlIsZeroMemory () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7ffacdeb5512 in ntdll!.misaligned_access () from C:\WINDOWS\SYSTEM32\ntdll.dll #2 0x7ffacdeb57fa in ntdll!.misaligned_access () from C:\WINDOWS\SYSTEM32\ntdll.dll #3 0x7ffacdebfce5 in ntdll!.misaligned_access () from C:\WINDOWS\SYSTEM32\ntdll.dll #4 0x7ffacddc8715 in ntdll!RtlGetCurrentServiceSessionId () from C:\WINDOWS\SYSTEM32\ntdll.dll #5 0x7ffacddc79e1 in ntdll!RtlFreeHeap () from C:\WINDOWS\SYSTEM32\ntdll.dll #6 0x7ffacb4e218b in ucrtbase!_free_base () from C:\WINDOWS\System32\ucrtbase.dll #7 0x7ffa7fd3eab6 in free_team (team=team@entry=0x25d609d0fc0) at ../../../gcc-12.1.0/libgomp/team.c:237 #8 0x7ffa7fd3ff8a in gomp_team_end () at ../../../gcc-12.1.0/libgomp/team.c:1005 #9 0x7ffa7fd3899e in GOMP_parallel_end () at ../../../gcc-12.1.0/libgomp/parallel.c:167 #10 0x7ffa7fd38a73 in GOMP_parallel ( fn=fn@entry=0x7ff707941530 , data=data@entry=0x0, num_threads=num_threads@entry=1, flags=flags@entry=0) at ../../../gcc-12.1.0/libgomp/parallel.c:179 #11 0x7ff707941584 in main () at myTest.cpp:2 For "#pragma omp for schedule(dynamic)" #0 0x7ffacdeac6b3 in ntdll!RtlIsZeroMemory () from C:\WINDOWS\SYSTEM32\ntdll.dll #1 0x7ffacdeb5512 in ntdll!.misaligned_access () from C:\WINDOWS\SYSTEM32\ntdll.dll #2 0x7ffacdeb57fa in ntdll!.misaligned_access () from C:\WINDOWS\SYSTEM32\ntdll.dll #3 0x7ffacdebfce5 in ntdll!.misaligned_access () from C:\WINDOWS\SYSTEM32\ntdll.dll #4 0x7ffacddc8715 in ntdll!RtlGetCurrentServiceSessionId () from C:\WINDOWS\SYSTEM32\ntdll.dll #5 0x7ffacddc79e1 in ntdll!RtlFreeHeap () from C:\WINDOWS\SYSTEM32\ntdll.dll #6 0x7ffacb4e218b in ucrtbase!_free_base () from C:\WINDOWS\System32\ucrtbase.dll #7 0x7ffa7eae050e in free_work_share (team=team@entry=0x0, ws=0x2b6040a8480) at ../../../gcc-12.1.0/libgomp/work.c:159 #8 0x7ffa7eae0682 in gomp_work_share_end () at ../../../gcc-12.1.0/libgomp/work.c:238 #9 0x7ffa7ead68b4 in GOMP_loop_end () at ../../../gcc-12.1.0/libgomp/loop.c:958 #10 0x7ff6b18f1593 in main () at myTest.cpp:3
[Bug target/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745 --- Comment #3 from Christoph Reiter --- Wild guess: I see _aligned_malloc() being used in libgomp, but not _aligned_free().
[Bug target/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745 --- Comment #4 from Christoph Reiter --- Yes, that's it I think. libgomp is mixing aligned malloc with unaligned free in various places.
[Bug target/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745 --- Comment #6 from Christoph Reiter --- Created attachment 53042 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53042&action=edit libgomp: use _aligned_free in gomp_aligned_free() if needed
[Bug target/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745 --- Comment #7 from Christoph Reiter --- Created attachment 53043 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53043&action=edit libgomp: don't use GOMP_USE_ALIGNED_WORK_SHARES on Windows
[Bug target/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745 --- Comment #8 from Christoph Reiter --- (In reply to Jakub Jelinek from comment #5) > Ugh, that is a lame limitation. > Does mingw support any of the other aligned allocators (memalign, > posix_memalign or aligned_alloc) that can be freed just with free? I don't think so. There is one internal one in https://github.com/mingw-w64/mingw-w64/blob/master/mingw-w64-crt/misc/mingw-aligned-malloc.c but that has the same limitation afaics. > If not, I guess easiest fix would be to move the HAVE__ALIGNED_MALLOC > support as last option before fallback instead of first, make sure > GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC is not defined for HAVE__ALIGNED_MALLOC if > no other aligned allocator works and use _aligned_free in gomp_aligned_free > if > HAVE__ALIGNED_MALLOC and not GOMP_HAVE_EFFICIENT_ALIGNED_ALLOC. I went with fixing gomp_aligned_free() and disabling GOMP_USE_ALIGNED_WORK_SHARES on Windows instead (hoping that in other cases gomp_aligned_free() is called properly.. (??)). With the goal in mind that this could be fixed if the alloc/free calls are paired properly in the future. Feedback welcome, or feel free to take over :)
[Bug libgomp/105745] [12/13 Regression] Conditional OpenMP directive fails with GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105745 --- Comment #10 from Christoph Reiter --- lgtm
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #15 from Christoph Reiter --- Still the same error with GCC 11.2 and binutils 2.37: https://github.com/msys2/MINGW-packages/pull/9088/checks?check_run_id=3196226530
[Bug ada/109670] New: SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670 Bug ID: 109670 Summary: SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13 Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: reiter.christoph at gmail dot com CC: dkm at gcc dot gnu.org Target Milestone: --- Updating from 12.2.0 to 13.1.0 we are encountering build errors for all ada packages on 32bit Windows, all failing with something like: raised SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES : s-pehage.adb:693 gnatmake: "broken.adb" compilation error I've reduced one ada example that fails down to: ``` with GNAT.Spitbol.Patterns; procedure Broken is M : GNAT.Spitbol.Patterns.Match_Result; type Header_Symbol is (None, Name, Attr, Conv, Prag); begin null; end Broken; ``` With GCC 12.2.0: ``` $ gnatmake.exe broken.adb gcc -c broken.adb gnatbind -x broken.ali gnatlink broken.ali ``` With GCC 13.1.0: ``` $ gnatmake.exe broken.adb gcc -c broken.adb raised SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES : s-pehage.adb:693 gnatmake: "broken.adb" compilation error ``` If there is any more info that I can provide or things I can try out please let me know.
[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670 --- Comment #1 from Christoph Reiter --- Could this be another case of exceptions being broken, as indicated here https://github.com/AdaCore/gnat-llvm/issues/25#issuecomment-1057198363 ? I see some "-static-libgcc" in the ada Makefile.in. I'll try building without that.
[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670 --- Comment #2 from Christoph Reiter --- (In reply to Christoph Reiter from comment #1) > [...] I'll try building without that. That didn't make a difference sadly.
[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670 --- Comment #3 from Christoph Reiter --- This looks very much like bug 108202 though, so I'll see if I can find something.
[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670 --- Comment #4 from Christoph Reiter --- Everything seems to be dynamically linked to libgcc, I'm out of ideas.
[Bug ada/108202] [13 Regression] Many new acats fails on 32bit Darwin hosts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108202 Christoph Reiter changed: What|Removed |Added CC||reiter.christoph at gmail dot com --- Comment #4 from Christoph Reiter --- There is a similar issue on Windows, bug 109670
[Bug ada/109670] SYSTEM.PERFECT_HASH_GENERATORS.TOO_MANY_TRIES compilation error on 32bit Windows starting with GCC 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670 --- Comment #5 from Christoph Reiter --- Taking `libgcc_s_dw2-1.dll` from gcc 12.2 fixes the issue. We also found that gdb and cmake are broken due to broken exception handling (in case of cmake it is flaky). In both those cases taking the old `libgcc_s_dw2-1.dll` also helps. So this is not ada specific, but exception handling being broken for 32bit Windows.
[Bug libgcc/109670] Exception handling broken for 32bit Windows starting with GCC 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670 Christoph Reiter changed: What|Removed |Added CC||tneumann at users dot sourceforge. ||net --- Comment #7 from Christoph Reiter --- Yes, I can confirm that reverting https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1c118c9970600117700cc12284587e0238de6bbe on top of 13.1.0 fixes exception handling, and cmake/ada/gdb work again.
[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 Christoph Reiter changed: What|Removed |Added CC||reiter.christoph at gmail dot com --- Comment #10 from Christoph Reiter --- I've compared [0] the stack size of the two builds now, and it looks like me setting BOOT_LDFLAGS [1] somehow made the build skip the stack size adjustment here: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=config/mh-mingw;h=e91367a711284148e16849d3066fb94599204a6c;hb=HEAD#l15 leading to the low Windows stack size defaults So this might not be a bug, but having built gcc wrong. [0] objdump.exe -x /ucrt64/lib/gcc/x86_64-w64-mingw32/13.1.0/cc1plus.exe | grep SizeOfStackReserve [1] https://github.com/msys2/MINGW-packages/commit/518e217a129eeeb92e5090f1bb14deaf0ed70edf#diff-cf683a120abf18dd9f774ea5df77137d01e19f359f7cb40c1fc152355cde7b80R265
[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670 --- Comment #15 from Christoph Reiter --- (In reply to Thomas Neumann from comment #12) > Created attachment 55037 [details] > radix sort fix > > I could reproduce the problem, the radix sort did not behave correctly when > we ran out of bits, which can happen on 32bit platforms. The attached patch > fixes the problem. I can confirm that this fixes the issue for me.
[Bug c++/115038] New: ICE in seh_cfa_offset since 14.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115038
Bug ID: 115038
Summary: ICE in seh_cfa_offset since 14.1.0
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reiter.christoph at gmail dot com
Target Milestone: ---
Downstream issue: https://github.com/msys2/MINGW-packages/issues/20861
The following code using GCC 14.1.0 on Windows targeting x86_64-w64-mingw32:
```
// gcc -c -fno-omit-frame-pointer -O2 repro.cpp
template void b(a, a);
template void c(a, a, float);
float d;
void e() {
float f;
c(f, f, d);
b(0.0f, f);
}
```
results in
```
repro.cpp: In function 'void e()':
repro.cpp:8:1: internal compiler error: in seh_cfa_offset, at
config/i386/winnt.cc:1137
8 | }
| ^
```
* Replacing "-O2" with "-O1" fixes the issue
* Removing "-fno-omit-frame-pointer" fixes the issue
* Downgrading to GCC 13.2.0 fixes the issue
If there is any other information I can provide, let me know.
[Bug target/115038] ICE in seh_cfa_offset since 14.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115038
--- Comment #1 from Christoph Reiter ---
Another downstream report with the same error:
https://github.com/msys2/MINGW-packages/issues/20864
I've c-reduced that as well to:
```
// gcc -c -fno-omit-frame-pointer -O2 repro.cpp
struct d {
d();
};
struct e {
e() : c(1.0) {}
float c;
};
struct j {
using ad = d;
};
class k : j {
d g;
e h;
};
template using i = k;
class {
i f;
} a;
k b;
```
[Bug target/115038] [14/15 regression] internal error in seh_cfa_offset with -O2 -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115038
--- Comment #5 from Christoph Reiter ---
Thanks! I can confirm that "-fno-fold-mem-offsets" works around the issue. I'll
test the proposed patch tomorrow.
In the meantime we've reduced another instance of this when building emacs, but
this time with "simpler" C code and without -fno-omit-frame-pointer:
```
// gcc -c -O2 repro.c -> internal compiler error: in seh_cfa_offset
// gcc -c -g3 -O2 -gdwarf-2 repro.c -> internal compiler error: in
dwarf2out_frame_debug_expr
void a() {
__builtin_unwind_init();
}
```
Adding this here for completeness.
[Bug target/115038] [14/15 regression] internal error in seh_cfa_offset with -O2 -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115038 --- Comment #6 from Christoph Reiter --- I can confirm that the patch from comment 4 fixes all the above cases, and also emacs builds again. Thanks again
[Bug c++/115190] -fmodule-mapper does not accept CRLF files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115190 Christoph Reiter changed: What|Removed |Added CC||reiter.christoph at gmail dot com --- Comment #7 from Christoph Reiter --- If the problem is indeed in read_tuple_file(), then I see one potential cause there: The file is opened in text mode and it checks if the read count matches the size of the actual data read. But in text mode where newline normalization happens the read part can be smaller if there are CRLF in there that got converted to LF: https://github.com/gcc-mirror/gcc/blob/0b3b6a8df77b0ae15078402ea5fb933d6fccd585/c%2B%2Btools/resolver.cc#L129-L130
[Bug c/120051] New: codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051
Bug ID: 120051
Summary: codeview ICE/segfault starting with 15.1.0
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: reiter.christoph at gmail dot com
Target Milestone: ---
$ gcc -dumpmachine
x86_64-w64-mingw32
$ cat test.c
// gcc -O1 -gcodeview -c test.c
void a();
static void b();
void c() { b(); }
void b() { a(); }
$ gcc -O1 -gcodeview -c test.c
test.c:5:1: internal compiler error: Segmentation fault
5 | void b() { a(); }
| ^~~~
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://github.com/msys2/MINGW-packages/issues> for instructions.
Let me know if there is anything else I can provide.
Downstream issue: https://github.com/msys2/MINGW-packages/issues/24148
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051
--- Comment #5 from Christoph Reiter ---
Thanks for working on this.
I applied the gcc patch and can confirm that the original example no longer
crashes. I found another crasher though and reduced it to:
$ cat test.c
// gcc -O1 -gcodeview -c test2.c
typedef union a b;
int c(b *) {}
$ gcc -O1 -gcodeview -c test2.c
test2.c:3:1: internal compiler error: Segmentation fault
3 | int c(b *) {}
| ^~~
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #13 from Christoph Reiter --- We found another crash in gegl. I'll try to reduce later.
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #21 from Christoph Reiter --- > Try removing the -g switch from the command line (leaving -gcodeview) - the combination of the -gcodeview -g switches (and in that order!) leads to such errors. Well, only those who know what SHOULD happen with such a combination of switches can "fix" it :). Removing "-g" does not change anything here. Note that this only occurs with 32bit builds, 64bit works fine. > And it seems to me that it is worth opening a separate ticket about this > situation (it appears on any source) and is not directly related to codeview > generation errors. OK, thanks
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051
--- Comment #8 from Christoph Reiter ---
Crasher with the latest patch:
// gcc -O1 -gcodeview -c test.c
void a(float *);
enum { b } c(long d) {
float e[d];
a(e);
}
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #11 from Christoph Reiter --- Thanks. With the latest patch + the patch for binutils, babl builds fine now.
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051
--- Comment #15 from Christoph Reiter ---
Thanks, that seems to have fixed the babl build.
Because I already had it, a reduced example:
$ cat test.c
// gcc -O2 -gcodeview -c test.c
typedef long a;
typedef int b;
int c(void *, void *, a);
b d() {
"" ? ({
char *e;
char *f = "";
{
a g;
c(e, 0, g);
}
})
: "";
}
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #18 from Christoph Reiter --- (In reply to Iouri Kharon from comment #17) > (In reply to Christoph Reiter from comment #16) > > (In reply to Christoph Reiter from comment #15) > > > Thanks, that seems to have fixed the babl build. > > > > ah, I meant the gegl build. > > And did you apply the patch that I posted on the 10th? > Because this example compiles for me. Yes. And yes, it compiles for me too. I just added the reduced example for future reference.
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #16 from Christoph Reiter --- (In reply to Christoph Reiter from comment #15) > Thanks, that seems to have fixed the babl build. ah, I meant the gegl build.
[Bug debug/120051] [15/16 regression] codeview ICE/segfault starting with 15.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120051 --- Comment #19 from Christoph Reiter --- After doing some more testing, the 32bit build now fails with these patches: [1/301] Compiling C++ object operations/external/exr-save.dll.p/exr-save.cc.obj FAILED: operations/external/exr-save.dll.p/exr-save.cc.obj "ccache" "c++" "-Ioperations/external/exr-save.dll.p" "-Ioperations/external" "-I../operations/external" "-I." "-I.." "-Igegl" "-I../gegl" "-Igegl/buffer" "-I../gegl/buffer" "-Igegl/graph" "-I../gegl/graph" "-Igegl/module" "-I../gegl/module" "-Igegl/opencl" "-I../gegl/opencl" "-Igegl/operation" "-I../gegl/operation" "-Igegl/process" "-I../gegl/process" "-Igegl/property-types" "-I../gegl/property-types" "-IC:/msys64/mingw32/include/babl-0.1" "-IC:/msys64/mingw32/include/glib-2.0" "-IC:/msys64/mingw32/lib/glib-2.0/include" "-IC:/msys64/mingw32/include/gio-win32-2.0" "-IC:/msys64/mingw32/include/OpenEXR" "-IC:/msys64/mingw32/include/Imath" "-fdiagnostics-color=always" "-D_GLIBCXX_ASSERTIONS=1" "-Wall" "-Winvalid-pch" "-std=gnu++14" "-O2" "-g" "-DHAVE_CONFIG_H" "-DGEGL_ENABLE_DEBUG" "-Winit-self" "-Wmissing-declarations" "-Wpointer-arith" "-Wno-unused-parameter" "-Wno-cast-function-type" "-D_FILE_OFFSET_BITS=64" "-gcodeview" "-ftree-vectorize" "-pthread" "-DLIBDEFLATE_DLL" -MD -MQ operations/external/exr-save.dll.p/exr-save.cc.obj -MF "operations/external/exr-save.dll.p/exr-save.cc.obj.d" -o operations/external/exr-save.dll.p/exr-save.cc.obj "-c" ../operations/external/exr-save.cc C:\msys64\tmp\ccR9hXob.s: Assembler messages: C:\msys64\tmp\ccR9hXob.s:19098: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19100: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19102: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19104: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19106: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19108: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19110: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19112: Error: can't resolve .text - Lcvline612 C:\msys64\tmp\ccR9hXob.s:19114: Error: can't resolve .text - Lcvline612 ...
