[Bug analyzer/109577] -Wanalyzer-allocation-size mishandles __builtin_mul_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109577 --- Comment #9 from nightstrike --- (In reply to David Malcolm from comment #8) > Should be fixed for GCC 13 (for the upcoming GCC 13.3) by the above patches. Did you miss my comment #5 highlighting the need to adjust the declaration of malloc such that size_t != long?
[Bug analyzer/110014] -Wanalyzer-allocation-size mishandles realloc (..., .... * sizeof (object))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110014 --- Comment #6 from nightstrike --- (In reply to David Malcolm from comment #5) > Should be fixed for GCC 13 (for the upcoming GCC 13.3) by the above patch. Did you miss my comment #3 that highlighted the problem due to assuming that size_t == long?
[Bug c++/114534] New: Feature request: extend VLA support in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114534 Bug ID: 114534 Summary: Feature request: extend VLA support in C++ Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- See https://gcc.gnu.org/pipermail/gcc-help/2024-March/143369.html for reference. The documentation at https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html states that VLAs are supported in C++ as an extension. Compiling the following: void f(int a, int b[a]); void f() { int c[2]; f(2, c); } with g++ -std=gnu++20 results in the error: "use of parameter outside function body before ']' token". The docs say nothing about partial support of VLA, just that they can be used. Where this is useful as an extension is in the somewhat reasonable case of including a C header in a C++ program. If that C header declares a function using a C99 VLA, it would be awesome if g++ were to accept it in -std=gnu++ mode (and it would be fine if it were rejected in -std=c++ mode). Consider a situation where you cannot modify the header, and so have to use it as-is. For comparison, clang added support for this feature in version 12. It would be advantageous to have feature parity given that it started as a GNU extension. Moreover, better interoperability with C is useful in its own right.
[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #8 from nightstrike --- (In reply to Andrew Pinski from comment #1) > This one looks like a mising '()': > ../../../gcc/gcc/ira-conflicts.cc:153:25: warning: format '%ld' expects > argument of type 'long int', but argument 3 has type 'long long unsigned > int' [-Wformat=] > 153 |"+++Allocating %ld bytes for conflict table (uncompressed > size %ld)\n", > | ~~^ > | | > | long int > | %lld > 154 |(long) allocated_words_num * sizeof (IRA_INT_TYPE), > |~~ > | | > | long long unsigned int > > Maybe it should have been `(long) (allocated_words_num * sizeof > (IRA_INT_TYPE))` > Likewise for the next one: > > 155 |(long) object_set_words * ira_objects_num * sizeof > (IRA_INT_TYPE)); > > Should have been `(long)(object_set_words * ira_objects_num * sizeof > (IRA_INT_TYPE))` This part should be fixed now after PR43613 and r14-8898-g2bb4556220285e.
[Bug target/43613] Some architecture-dependent codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613 --- Comment #10 from nightstrike --- Patch thread started here: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644674.html https://inbox.sourceware.org/gcc-patches/4700e066-1b50-4e7b-92f7-d8c33a330...@gmail.com/ and ended with this solution: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644701.html https://inbox.sourceware.org/gcc-patches/Zbu34FTR73081bMb@tucnak/ which was committed in r14-8898-g2bb4556220285e. I believe based on comment 7, this can now be closed.
[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755 --- Comment #6 from nightstrike --- (In reply to nightstrike from comment #5) > If I open your godbolt links, they aren't using a Windows target compiler, > so they aren't exercising an LLP64 target. For instance: https://godbolt.org/z/4Mx96Wjvd : In function 'XLI': :15:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 15 | return (EMACS_INT) o; | ^ ASM generation compiler returned: 0 ERROR: The inherited access control list (ACL) or access control entry (ACE) could not be built. : In function 'XLI': :15:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 15 | return (EMACS_INT) o; | ^ Execution build compiler returned: 0 Program returned: 254
[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755 --- Comment #5 from nightstrike --- (In reply to David Malcolm from comment #4) > Looks like this was fixed sometime in GCC 13; resolving as WORKSFORME. > > Feel free to reopen if you have a reproducer that triggers on a more recent > GCC. The testcase still fails. To be clear, I'm referring to null-deref-pr105755.c: Executing on host: /tmp/gcc/src/gcc-git/_w/gcc/xgcc -B/tmp/gcc/src/gcc-git/_w/gcc/ exceptions_enabled705865.cc -fdiagnostics-plain-output -Wno-complain-wrong-lang -S -o exceptions_enabled705865.s(timeout = 300) spawn -ignore SIGHUP /tmp/gcc/src/gcc-git/_w/gcc/xgcc -B/tmp/gcc/src/gcc-git/_w/gcc/ exceptions_enabled705865.cc -fdiagnostics-plain-output -Wno-complain-wrong-lang -S -o exceptions_enabled705865.s^M FAIL: gcc.dg/analyzer/null-deref-pr105755.c (test for excess errors) Excess errors: /tmp/gcc/src/gcc-git/gcc/testsuite/gcc.dg/analyzer/null-deref-pr105755.c:19:10: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] testcase /tmp/gcc/src/gcc-git/gcc/testsuite/gcc.dg/analyzer/analyzer.exp completed in 0 seconds With this change: --- a/gcc/testsuite/gcc.dg/analyzer/null-deref-pr105755.c +++ b/gcc/testsuite/gcc.dg/analyzer/null-deref-pr105755.c @@ -2,7 +2,7 @@ /* { dg-additional-options "-Wno-analyzer-too-complex -Wno-analyzer-symbol-too-complex -O2" } */ typedef long int ptrdiff_t; -typedef long int EMACS_INT; +typedef __UINTPTR_TYPE__ EMACS_INT; typedef long int intmax_t; enum Lisp_Type Then I get this: PASS: gcc.dg/analyzer/null-deref-pr105755.c (test for excess errors) If I open your godbolt links, they aren't using a Windows target compiler, so they aren't exercising an LLP64 target. Generally speaking, most of the analyzer testsuite assumes incorrect definitions of things. For instance, in the diff I just posted, you can see that the lines before and after also assume the underlying types of ptrdiff_t and intmax_t instead of using compiler builtins or just including the relevant headers. This is really needs to be fixed across the whole testsuite.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #35 from nightstrike --- (In reply to anlauf from comment #34) > Are you sure that it finds the right new libgfortran? Good call. I did a make install first and re-ran it, and they all pass now. Sorry for the noise, this is an unfortunate aspect of the testsuite where in many cases it will not use the just-built libraries, but instead picks up the libraries in the install path.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #33 from nightstrike --- I modified the test further to just print which ones would have called stop. Almost, but not all, do: stop 2 stop 3 stop 4 stop 7 stop 8 stop 9 stop 10 stop 11 stop 12 stop 13 stop 15 stop 20 stop 21 stop 22 stop 23 stop 24 stop 25 stop 26 stop 27 stop 28 stop 29 stop 30 stop 31 stop 32
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #32 from nightstrike --- (In reply to anlauf from comment #31) > (In reply to nightstrike from comment #30) > > (In reply to GCC Commits from comment #29) > > > * gfortran.dg/pr111022.f90: New test. > > > > This new test fails of x64 mingw. > > Can you be more specific? Sure, it exits with STOP 2, which is the following: write(buffer,"(EN0.3E0)") 6.660_4 if (buffer.ne."6.660E+0") stop 2 I modified that as: write(buffer,"(EN0.3E0)") 6.660_4 if (buffer.ne."6.660E+0") then print *, buffer stop 2 end if And now it prints: 6.660 STOP 2 So I guess it's losing the E+0 from the string?
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #30 from nightstrike --- (In reply to GCC Commits from comment #29) > * gfortran.dg/pr111022.f90: New test. This new test fails of x64 mingw.
[Bug c++/113624] FAIL: g++.dg/ext/dllimport4.C, ICE on windows targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113624 nightstrike changed: What|Removed |Added Known to fail||11.3.0, 12.2.0, 13.0, 14.0 --- Comment #1 from nightstrike --- To be clear, the ICE happens on 11, 12, 13, and 14. I don't have other versions handy to test.
[Bug analyzer/105755] -Wanalyzer-null-dereference regression compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105755 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #2 from nightstrike --- (In reply to GCC Commits from comment #1) > * gcc.dg/analyzer/null-deref-pr105755.c: Likewise. In this test, the XLI function tries to store a pointer in a long. That type should be __UINTPTR_TYPE__ instead; we see warnings on any LLP64 system.
[Bug analyzer/109577] -Wanalyzer-allocation-size mishandles __builtin_mul_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109577 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #5 from nightstrike --- (In reply to David Malcolm from comment #4) > Thanks for fixing this Tim. > > Keeping open to track backporting this to the gcc 13 branch. Before this gets backported, the testcase should be fixed. It uses an incorrect declaration of malloc, assuming that size_t is long. The standard defines malloc as size_t, so the declaration should use __SIZE_TYPE__ instead. This works, although you could also just include stdlib.h or use __builtin_malloc.
[Bug analyzer/110014] -Wanalyzer-allocation-size mishandles realloc (..., .... * sizeof (object))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110014 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #3 from nightstrike --- (In reply to David Malcolm from comment #2) > Thanks for fixing this Tim. > > Keeping open to track backporting this to the gcc 13 branch. Before this gets backported, the testcase should be fixed. It uses an incorrect declaration of realloc, assuming that size_t is long. The standard defines realloc as size_t, so the declaration should use __SIZE_TYPE__ instead. This works, although you could also just include stdlib.h or use __builtin_realloc.
[Bug testsuite/113634] New: FAIL: gcc.dg/Wfree-nonheap-object-7.c, incorrect declaration for calloc()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113634 Bug ID: 113634 Summary: FAIL: gcc.dg/Wfree-nonheap-object-7.c, incorrect declaration for calloc() Product: gcc Version: unknown Status: UNCONFIRMED Keywords: testsuite-fail Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- This test uses an incorrect declaration for calloc(): void *calloc(long, long); whereas the standard requires that it be: void *calloc(size_t, size_t); This can be replaced with: void *calloc(__SIZE_TYPE__, __SIZE_TYPE__); But I'd question why the test doesn't just include stdlib.h. Or, if the intent is to avoid including headers as much as possible, use __builtin_calloc(), which does the right thing. All three of these solutions work (header, builtin, correct declaration).
[Bug target/113633] New: FAIL: gcc.dg/bf-ms-attrib.c execution test, wrong size for ms_struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113633 Bug ID: 113633 Summary: FAIL: gcc.dg/bf-ms-attrib.c execution test, wrong size for ms_struct Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ABI, testsuite-fail Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com CC: ktietz at gcc dot gnu.org Target Milestone: --- Target: *-*-mingw* *-*-cygwin* >From gcc.dg/bf-ms-attrib.c: struct one_ms { int d; unsigned char a; unsigned short b:7; char c; } __attribute__((__ms_struct__)); And later: if (sizeof(struct one_ms) != 8) abort(); Here, we abort, because the size is 12 using the MS ABI. Curiously, the testcase as initially committed used 12, and it was changed to 8 in r0-115284-g4d33b77106cf7f with the description being: gcc.dg/bf-ms-attrib.c: Adjust expected size for ms_struct layout. However, MSVC (and gcc/cygwin FWIW) creates a 12-byte struct, so I am curious which is correct. Should that portion of that commit be reverted, or should the struct be packed into 8 bytes? If you happen to still be reading this, Kai, would you mind weighing in? Perhaps we were incorrectly making 8-byte structs, then changed the testcase to match 8, and later fixed something to generate 12-byte structs?
[Bug c/113631] New: FAIL: gcc.dg/pr7356.c, fix still fails with #pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113631 Bug ID: 113631 Summary: FAIL: gcc.dg/pr7356.c, fix still fails with #pragma Product: gcc Version: unknown Status: UNCONFIRMED Keywords: diagnostic, testsuite-fail Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com CC: dmalcolm at gcc dot gnu.org Target Milestone: --- The original PR7356 highlighted a problem where a diagnostic for a problem in a source file would point to something in an included file. This was fixed for the case in the PR for a subset of systems with certain standard header files. The original testcase was: a #include #include #include int main(int argc, char** argv) { return 0; } The expectation is that GCC warns on the 'a', not somewhere inside stdlib.h. This now works as indicated in that PR: :1:2: error: expected ';' before 'typedef' 1 | a | ^ | ; Notably, it works differently with C++: :1:1: error: 'a' does not name a type 1 | a | ^ ...but at least it marks 'a' as the issue (should that be a separate PR?) However, on mingw, we have certain constructs in our headers that still confuse the parser, resulting in this: In file included from /tmp/rt/mingw14/x86_64-w64-mingw32/include/_mingw.h:282,^M from /tmp/rt/mingw14/x86_64-w64-mingw32/include/corecrt.h:10,^M from /tmp/rt/mingw14/x86_64-w64-mingw32/include/stdlib.h:9,^M from /tmp/gcc/testsuite/gcc.dg/pr7356.c:4:^M /tmp/rt/mingw14/x86_64-w64-mingw32/include/vadefs.h:14:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before '#pragma'^M #pragma pack(push,_CRT_PACKING)^M ^~~~^M It turns out that the problem is target-agnostic and is really just due to pragmas, so I've reduced it and reproduced the problem on GNU/Linux (the pragma is meant to be a no-op, that was a close approximation. GCC diagnostic push also works): a.c: a #include "a.h" int main() {} a.h: #pragma message "foo" $ gcc -c a.c a.h:1:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before '#pragma' 1 | #pragma message "foo" | ^~~ a.h:1:9: note: '#pragma message: foo'
[Bug c++/113624] New: FAIL: g++.dg/ext/dllimport4.C, ICE on windows targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113624 Bug ID: 113624 Summary: FAIL: g++.dg/ext/dllimport4.C, ICE on windows targets Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Created attachment 57235 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57235&action=edit output of -freport-bug A test from the testsuite is failing for extra errors, but it also ICE's, so this PR is to document the ICE. This is the reduced dllimport4.C: void faz() { __attribute__((dllimport)) int faa = 1; faa++; } $ x86_64-w64-mingw32-g++ -c dllimport4.C dllimport4.C: In function 'void faz()': dllimport4.C:2:34: error: variable 'faa' definition is marked dllimport 2 | __attribute__((dllimport)) int faa = 1; | ^~~ dllimport4.C:4:1: internal compiler error: Segmentation fault 4 | } | ^ 0x138a72f crash_signal ../../gcc/toplev.cc:317 0xb1287b cp_genericize_r ../../gcc/cp/cp-gimplify.cc:1620 0x16bddbc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc/tree.cc:11420 0xdae64f c_genericize_control_stmt(tree_node**, int*, void*, tree_node* (*)(tree_node**, int*, void*), tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc/c-family/c-gimplify.cc:557 0xb12aab cp_genericize_r ../../gcc/cp/cp-gimplify.cc:2225 0x16bddbc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc/tree.cc:11420 0xb13e9f cp_genericize_r ../../gcc/cp/cp-gimplify.cc:1836 0x16bddbc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc/tree.cc:11420 0xb12091 cp_genericize_tree ../../gcc/cp/cp-gimplify.cc:2258 0xb12409 cp_genericize(tree_node*) ../../gcc/cp/cp-gimplify.cc:2400 0xb62716 finish_function(bool) ../../gcc/cp/decl.cc:18800 0xc695b7 cp_parser_function_definition_after_declarator ../../gcc/cp/parser.cc:32699 0xc6a74e cp_parser_function_definition_from_specifiers_and_declarator ../../gcc/cp/parser.cc:32613 0xc6a74e cp_parser_init_declarator ../../gcc/cp/parser.cc:23356 0xc3dcd4 cp_parser_simple_declaration ../../gcc/cp/parser.cc:15890 0xc770ba cp_parser_declaration ../../gcc/cp/parser.cc:15563 0xc77f9a cp_parser_toplevel_declaration ../../gcc/cp/parser.cc:15584 0xc77f9a cp_parser_translation_unit ../../gcc/cp/parser.cc:5276 0xc77f9a c_parse_file() ../../gcc/cp/parser.cc:51174 0xdc6531 c_common_parse_file() ../../gcc/c-family/c-opts.cc:1301 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-w64-mingw32-g++ -v Using built-in specs. COLLECT_GCC=x86_64-w64-mingw32-g++ COLLECT_LTO_WRAPPER=/tmp/rt/mingw14/bin/../libexec/gcc/x86_64-w64-mingw32/14.0.1/lto-wrapper Target: x86_64-w64-mingw32 Configured with: ../configure --disable-multilib --disable-nls --target=x86_64-w64-mingw32 --prefix=/tmp/rt/mingw14 --with-sysroot=/tmp/rt/mingw14 --enable-languages=c,ada,c++,d,fortran,lto,m2,objc,obj-c++,rust Thread model: win32 Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240126 (experimental) (GCC)
[Bug c++/113591] New: FAIL: g++.dg/cpp0x/lambda/lambda-ice15.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113591 Bug ID: 113591 Summary: FAIL: g++.dg/cpp0x/lambda/lambda-ice15.C Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- See PR 67846. The original PR highlighted an ICE, and we do not ICE on Windows, but we don't error out either. We can achieve the Linux behavior with -fno-ms-extensions on Windows, and the Windows behavior with -fms-extensions on Linux. If we assume that the behavior is an intended MS Extension, then it would be good to have the testsuite verify that the error happens only with those disabled and doesn't happen with them enabled. If it's not an intended extension, then this PR could stand to document the needed fix. N This is the part of the testcase that fails to error out on Windows: ``` class A { void foo() { [=] { return foo; }; } }; ``` On Linux: $ g++ -c a.cc -fms-extensions $ g++ -c a.cc a.cc: In lambda function: a.cc:3:30: error: cannot convert 'A::foo' from type 'void (A::)()' to type 'void (A::*)()' 3 | [=] { return foo; }; | ^~~ $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/tmp/gcc/rt/linux14/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../configure --disable-nls --disable-multilib --prefix=/tmp/rt/linux14 --enable-languages=all Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240116 (experimental) (GCC) On Windows: $ x86_64-w64-mingw32-g++ -c a.cc $ x86_64-w64-mingw32-g++ -c a.cc -fno-ms-extensions a.cc: In lambda function: a.cc:3:30: error: cannot convert 'A::foo' from type 'void (A::)()' to type 'void (A::*)()' 3 | [=] { return foo; }; | ^~~ $ x86_64-w64-mingw32-g++ -v Using built-in specs. COLLECT_GCC=x86_64-w64-mingw32-g++ COLLECT_LTO_WRAPPER=/tmp/gcc/rt/mingw14/bin/../libexec/gcc/x86_64-w64-mingw32/14.0.1/lto-wrapper Target: x86_64-w64-mingw32 Configured with: ../configure --disable-multilib --disable-nls --target=x86_64-w64-mingw32 --prefix=/tmp/rt/mingw14 --with-sysroot=/tmp/rt/mingw14 --enable-languages=c,ada,c++,d,fortran,lto,m2,objc,obj-c++,rust Thread model: win32 Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240120 (experimental) (GCC)
[Bug libstdc++/113589] New: FAIL: experimental/filesystem/operations/absolute.cc on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113589 Bug ID: 113589 Summary: FAIL: experimental/filesystem/operations/absolute.cc on Windows Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- (Probably related to PR4) The absolute.cc test fails this assertion: VERIFY( absolute(p).is_absolute() ); on the second path in __gnu_test::test_paths, I think because absolute(p).has_root_name() returns false: ``` std::cout << absolute(p) << std::endl; std::cout << "has: " << absolute(p).has_root_name() << " " << absolute(p).has_root_directory() << std::endl; VERIFY( absolute(p).is_absolute() ); ``` ``` spawn wine64 ./absolute.exe^M "H:/"^M^M has: 1 1^M^M "//\\home\\user\\p\\gcc\\src\\gcc-git\\_w\\x86_64-w64-mingw32\\libstdc++-v3\\testsuite"^M^M has: 0 1^M^M ``` So H:/ works, but //\\path doesn't. I guess all these extra slashes are due to running under wine, but presumably real applications may do so. absolute() does the following: ``` if (p.has_root_directory()) // implies !p.has_root_name() { // GetFullPathNameW("//") gives unwanted result (PR 4). // If there are multiple directory separators at the start, // skip all but the last of them. const auto pos = s.find_first_not_of(L"/\\"); __glibcxx_assert(pos != 0); s.remove_prefix(std::min(s.length(), pos) - 1); } ``` So I guess this needs to be a little bit smarter to handle Wine paths maybe? Sorry I couldn't take this further, but I'll be happy to test a fix.
[Bug target/100058] -Wpadded is inconsistent using -mms-bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100058 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #1 from nightstrike --- (In reply to Josh Nave from comment #0) > Someone else suggested that the line `!targetm.ms_bitfield_layout_p > (rli->t)` in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52238 could be the > issue, which to me seems likely from a brief look. I don't think it's as simple as just removing those conditions, as they're trying to restrict warning for MS-specific cases. We need to understand under which conditions it's expected to warn when -mms-bitfields is enabled.
[Bug target/113549] float simd crash on windows in gcc.dg/vect/vect-simd-clone-16b.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113549 --- Comment #4 from nightstrike --- (In reply to Andrew Pinski from comment #3) > Either the stack size or the stack alignment issue. > > I am suspecting a stack alignement issue. Possibly related: PR110273
[Bug testsuite/113548] gcc.dg/vect/vect-ifcvt-19.c ICEs on LLP64 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113548 --- Comment #3 from nightstrike --- Seeing as how this is a testsuite issue, it seems that the crash in the same location applies to the following: FAIL: gcc.dg/vect/vect-ifcvt-19.c (internal compiler error: in build2, at tree.cc:5097) FAIL: gcc.dg/vect/slp-reduc-10a.c (internal compiler error: in build2, at tree.cc:5097) FAIL: gcc.dg/vect/slp-reduc-10b.c (internal compiler error: in build2, at tree.cc:5097) FAIL: gcc.dg/vect/slp-reduc-10c.c (internal compiler error: in build2, at tree.cc:5097) FAIL: gcc.dg/vect/slp-reduc-10d.c (internal compiler error: in build2, at tree.cc:5097) FAIL: gcc.dg/vect/slp-reduc-10e.c (internal compiler error: in build2, at tree.cc:5097) FAIL: gcc.dg/vect/vect-ifcvt-19.c -flto -ffat-lto-objects (internal compiler error: in build2, at tree.cc:5097) FAIL: gcc.dg/vect/vect-cond-arith-2.c -flto -ffat-lto-objects (internal compiler error: in build2, at tree.cc:5097) FAIL: gcc.dg/vect/vect-cond-arith-2.c (internal compiler error: in build2, at tree.cc:5097) FAIL: gcc.dg/vect/slp-reduc-10b.c -flto -ffat-lto-objects (internal compiler error: in build2, at tree.cc:5097) FAIL: gcc.dg/vect/slp-reduc-10c.c -flto -ffat-lto-objects (internal compiler error: in build2, at tree.cc:5097) FAIL: gcc.dg/vect/slp-reduc-10d.c -flto -ffat-lto-objects (internal compiler error: in build2, at tree.cc:5097) FAIL: gcc.dg/vect/slp-reduc-10e.c -flto -ffat-lto-objects (internal compiler error: in build2, at tree.cc:5097)
[Bug target/113549] float simd crash on windows in gcc.dg/vect/vect-simd-clone-16b.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113549 --- Comment #2 from nightstrike --- Test 16e uses double instead of float, which also crashes.
[Bug target/113549] float simd crash on windows in gcc.dg/vect/vect-simd-clone-16b.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113549 --- Comment #1 from nightstrike --- Created attachment 57188 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57188&action=edit Failing source for easier copying
[Bug target/113549] New: float simd crash on windows in gcc.dg/vect/vect-simd-clone-16b.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113549 Bug ID: 113549 Summary: float simd crash on windows in gcc.dg/vect/vect-simd-clone-16b.c Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Created attachment 57187 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57187&action=edit Assembly output The vect-simd-clone-16b.c test runs the vect-simd-clone-16.c test with the TYPE set to float. The default type is int, which works fine. Reducing that testcase yields the following: ``` #define TYPE float #pragma omp declare simd inbranch TYPE __attribute__((noinline)) foo (TYPE a) { return a + 1; } void masked_fixed (TYPE * a, TYPE * b) { #pragma omp simd for (int i = 0; i < 128; i++) b[i] = a[i]<1 ? foo(a[i]) : a[i]; } int main() { TYPE a[1024] = {0}; TYPE b[1024] = {0}; masked_fixed(a, b); return 0; } ``` The noipa attribute and the __restrict keywords were removed from masked_fixed. noinline is required on foo. Minimal set of compile arguments required to trigger the problem: $ x86_64-w64-mingw32-gcc a.c -fopenmp-simd -O2 -mavx Note that dropping to -01 or removing -mavx avoids the crash. Assembly from -save-temps -fverbose-asm attached. This is technically running under wine 8.0. This is the backtrace provided by wine: ``` wine: Unhandled page fault on read access to at address 00014000163F (thread 0024), starting debugger... Unhandled exception: page fault on read access to 0x in 64-bit code (0x014000163f). Register dump: rip:00014000163f rsp:0021dc50 rbp:0021dcd0 eflags:00010246 ( R- -- I Z- -P- ) rax: rbx: rcx:0021dcf0 rdx:0021dcd0 rsi:0021ed70 rdi:0021dd70 r8:0021dcb0 r9:00c92000 r10:00c90330 r11: r12:0021dcb0 r13:0021dcf0 r14: r15: Stack dump: 0x21dc50: 0x21dc60: 0x21dc70: 0x21dc80: 0x21dc90: 0x21dca0: 0x21dcb0: 0x21dcc0: 0x21dcd0: 0x21dce0: 0x21dcf0: 0x21dd00: Backtrace: =>0 0x014000163f in a (+0x163f) (0x21dcd0) 1 0x0140003384 in a (+0x3384) (0x21fdf0) 2 0x0140001340 in a (+0x1340) (0x21fdf0) 3 0x0140001146 in a (+0x1146) (0x21fe30) 4 0x007b647b51 BaseThreadInitThunk+0x11(unknown=, entry=, arg=) [H:\home\user\p\gcc\src\wine-8.0-rc4p2p3\dlls\kernel32\thread.c:61] in kernel32 (0x0 00021fe60) 0x014000163f a+0x163f: ldsl %esp,%edi ```
[Bug tree-optimization/113548] New: ICE vect-ifcvt-19 in build2, at tree.cc:5097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113548 Bug ID: 113548 Summary: ICE vect-ifcvt-19 in build2, at tree.cc:5097 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Created attachment 57186 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57186&action=edit Preprocessed source from -freport-bug ICE during testsuite run for vect-ifcvt-19. Many similarly titled bugs, I think the current title of this one is equally unhelpful, so feel free to change this PR title to something better. Running linux 64 to windows 64 cross compiler, fails on 11, 12, 13, 14. I didn't test prior versions. Backtrace: 0x8bb855 build2(tree_code, tree_node*, tree_node*, tree_node*) ../../gcc/tree.cc:5097 0xa4dd1f build2_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) ../../gcc/tree.h:4750 0xa4dd1f c_parser_gimple_binary_expression ../../gcc/c/gimple-parser.cc:1068 0xa4ec71 c_parser_gimple_statement ../../gcc/c/gimple-parser.cc:878 0xa4f95a c_parser_gimple_compound_statement ../../gcc/c/gimple-parser.cc:669 0xa51a58 c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il, profile_count) ../../gcc/c/gimple-parser.cc:253 0xa3d3f4 c_parser_declaration_or_fndef ../../gcc/c/c-parser.cc:3011 0xa4764b c_parser_external_declaration ../../gcc/c/c-parser.cc:2046 0xa48035 c_parser_translation_unit ../../gcc/c/c-parser.cc:1900 0xa48035 c_parse_file() ../../gcc/c/c-parser.cc:26815 0xabf271 c_common_parse_file() ../../gcc/c-family/c-opts.cc:1301
[Bug libstdc++/107603] checking for ld that supports -Wl,--gc-sections... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. for i686-w64-mingw32 target at canadian compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107603 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #2 from nightstrike --- That config.log output isn't in the attached file. I think you attached the top level config.log and not the libstdc++ config.log. Can you try again?
[Bug target/59425] ICE - seg fault building ISL on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59425 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #2 from nightstrike --- The preprocessed source works for me in 13. Can you verify if this is still an issue?
[Bug ada/113516] New: POLLPRI redefined on windows building ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113516 Bug ID: 113516 Summary: POLLPRI redefined on windows building ada Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com CC: dkm at gcc dot gnu.org Target Milestone: --- g:r11-4313-gd08d481912b9a2 defined POLLPRI to zero on Windows, stating in the commit message "Define POLLPRI as zero on Windows as it is not supported there." However, it is defined on mingw-w64 targets, resulting in a build warning: /tmp/gcc/src/gcc-git/gcc/ada/s-oscons-tmplt.c:1871:9: warning: "POLLPRI" redefined 1871 | #define POLLPRI 0 | ^~~ In file included from /tmp/gcc/src/gcc-git/gcc/ada/gsocket.h:83, from /tmp/gcc/src/gcc-git/gcc/ada/s-oscons-tmplt.c:103: /tmp/rt/mingw14/x86_64-w64-mingw32/include/winsock2.h:1182:9: note: this is the location of the previous definition 1182 | #define POLLPRI0x0400 | ^~~
[Bug libstdc++/65257] cin not working with empty string when _GLIBCXX_DEBUG is defined on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65257 --- Comment #2 from nightstrike --- I should clarify that I tested this with mingw-w64, not mingw.org where the bug was originally reported.
[Bug libstdc++/65257] cin not working with empty string when _GLIBCXX_DEBUG is defined on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65257 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #1 from nightstrike --- (In reply to Muhammad Annaqeeb from comment #0) > #define _GLIBCXX_DEBUG > #include > using namespace std; > string s,t; > int main(){ > cin>>s>>t; > cout< } FWIW, this works on Wine as well as Cygwin + Win 7, compiled with g++ 14, configured *without* --enable-fully-dynamic-string.
[Bug target/43613] Some architecture-dependent codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #8 from nightstrike --- (In reply to Andrew Pinski from comment #7) > So just this one left I think: > > /gcc/src/gcc/ira-conflicts.c: Line 125: > > Still there, size_t is long long (64bits) while long is 32bits. Assuming this is now line 153: ``` diff --git a/gcc/ira-conflicts.cc b/gcc/ira-conflicts.cc index a4d93c8d734..4f2c2bdfebc 100644 --- a/gcc/ira-conflicts.cc +++ b/gcc/ira-conflicts.cc @@ -150,9 +150,9 @@ build_conflict_bit_table (void) if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL) fprintf (ira_dump_file, - "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n", - (long) allocated_words_num * sizeof (IRA_INT_TYPE), - (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)); + "+++Allocating %zu bytes for conflict table (uncompressed size %zu)\n", + (size_t)(allocated_words_num * sizeof (IRA_INT_TYPE)), + (size_t)(object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE))); objects_live = sparseset_alloc (ira_objects_num); for (i = 0; i < ira_max_point; i++) ``` Perhaps that will address the remaining issue?
[Bug libstdc++/110167] New: excessive compile time when optimizing std::to_array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110167 Bug ID: 110167 Summary: excessive compile time when optimizing std::to_array Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- #include int f[262144]; auto g(void) { return std::to_array(f); } (Thanks to Andrew for help reducing!) Baseline run: $ time g++ test.cc -std=gnu++20 -O0 -c real0m17.274s user0m16.806s sys 0m0.119s at -O1, 2, 3, or fast, it takes too long to ever finish. I killed it after 15 minutes. For the curious, that array size is 512*512. I didn't bisect to see where it starts to blow up.
[Bug target/69639] [10/11/12/13 Regression] FAIL: gcc.c-torture/compile/limits-exprparen.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69639 --- Comment #18 from nightstrike --- (In reply to nightstrike from comment #9) > This affects 8-trunk on x86_64 cygwin, as well. The default size of the > stack for cc1 is: > > $ peflags -x /tmp/b2/gcc/cc1.exe > /tmp/b2/gcc/cc1.exe: stack reserve size : 12582912 (0xc0) bytes > > > Setting it to 0xd0 and 0xe0 also fail. Setting it to 0xf0 > works. I didn't go further than that to see where between 14 and 15 megs it > starts working. > > Can we just boost the default stack size of cc1.exe by a couple megs for > affected hosts? It looks like Dave Korn already did it here: https://gcc.gnu.org/legacy-ml/gcc-patches/2010-12/msg00256.html But 12 isn't enough. We need 15 (or I guess 16 if you like powers of 2).
[Bug c/108942] New: ICE in build2, at tree.c: 5096 for gcc/testsuite/gcc.dg/torture/ssa-fre-7.c:23:3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108942 Bug ID: 108942 Summary: ICE in build2, at tree.c: 5096 for gcc/testsuite/gcc.dg/torture/ssa-fre-7.c:23:3 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Created attachment 54541 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54541&action=edit preprocessed source from -freport-bug The gcc.dg/torture/ssa-fre-7.c tests fail with the following backtrace: 0x844e1f build2(tree_code, tree_node*, tree_node*, tree_node*) ../../gcc/tree.cc:5096 0x9a26d7 build2_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) ../../gcc/tree.h:4604 0x9a26d7 c_parser_gimple_binary_expression ../../gcc/c/gimple-parser.cc:1027 0x9a38ce c_parser_gimple_statement ../../gcc/c/gimple-parser.cc:873 0x9a38ce c_parser_gimple_compound_statement ../../gcc/c/gimple-parser.cc:664 0x9a5c11 c_parser_parse_gimple_body(c_parser*, char*, c_declspec_il, profile_count) ../../gcc/c/gimple-parser.cc:253 0x9954a6 c_parser_declaration_or_fndef ../../gcc/c/c-parser.cc:2835 0x99c6fb c_parser_external_declaration ../../gcc/c/c-parser.cc:1925 0x99d0d3 c_parser_translation_unit ../../gcc/c/c-parser.cc:1779 0x99d0d3 c_parse_file() ../../gcc/c/c-parser.cc:24632 0xa088e1 c_common_parse_file() ../../gcc/c-family/c-opts.cc:1248 This is in a linux to 64-bit windows cross compiler environment. Output of -freport-bug added as an attachment. For this version of the repository (commit e6d39f68d03c46637ca6e1bede3d28eae6278df3), line 23 is: p_4 = _Literal (int *) &x + _2;
[Bug middle-end/83286] internal compiler error: Illegal instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83286 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #9 from nightstrike --- I compiled both of the preprocessed source attachments and could not reproduce your failure using a recently built gcc 13 cross compiler from linux to x86_64-w64-mingw32. I used no options, "-O3 -Wall -fno-strict-aliasing -fomit-frame-pointer-funroll-loops -fPIC", and "-O3 -Wall -fno-strict-aliasing" based on your command lines. Is it safe to assume that this is no longer an issue?
[Bug target/90458] [10/11/12/13 Regression] mingw64: ICE in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1258 with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458 --- Comment #8 from nightstrike --- FYI, this is the same as the failure in gcc/testsuite/gcc.dg/stack-check-16.c: (running this under Wine) during RTL pass: final gcc.dg/stack-check-16.c:36:1: internal compiler error: in i386_pe_seh_unwind_emit, at config/i386/winnt.cc:1274^M 0x86f42f i386_pe_seh_unwind_emit(_IO_FILE*, rtx_insn*)^M ../../gcc/config/i386/winnt.cc:1274^M 0xbd4d87 final_scan_insn_1^M ../../gcc/final.cc:2851^M 0xbd515b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)^M ../../gcc/final.cc:2887^M 0xbd5347 final_1^M ../../gcc/final.cc:1979^M 0xbd5e36 rest_of_handle_final^M ../../gcc/final.cc:4240^M 0xbd5e36 execute^M ../../gcc/final.cc:4318^M Please submit a full bug report, with preprocessed source (by using -freport-bug).^M Please include the complete backtrace with any bug report.^M See <https://gcc.gnu.org/bugs/> for instructions.^M compiler exited with status 1
[Bug testsuite/108675] FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675 --- Comment #9 from nightstrike --- I understand it's not ideal based on comment #6, but this fixes all the tests: diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c index 853a705e86d..499c81b0fa7 100644 --- a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c +++ b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c @@ -1,11 +1,10 @@ -#include #include extern void abort (void); extern int inside_main; __attribute__ ((__noinline__)) int -fprintf (FILE *fp, const char *string, ...) +fprintf (void *fp, const char *string, ...) { va_list ap; int r; @@ -22,7 +21,7 @@ fprintf (FILE *fp, const char *string, ...) /* Locking stdio doesn't matter for the purposes of this test. */ __attribute__ ((__noinline__)) int -fprintf_unlocked (FILE *fp, const char *string, ...) +fprintf_unlocked (void *fp, const char *string, ...) { va_list ap; int r; diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c index 4be7578d124..0d405241cfe 100644 --- a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c +++ b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/printf.c @@ -1,4 +1,3 @@ -#include #include extern void abort (void); extern int inside_main; diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/sprintf.c b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/sprintf.c index 3ac447b117f..6de24cd7df4 100644 --- a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/sprintf.c +++ b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/sprintf.c @@ -1,4 +1,3 @@ -#include #include extern void abort (void); extern int inside_main;
[Bug testsuite/108709] FAIL: gcc.dg/analyzer/pipe-glibc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108709 --- Comment #1 from nightstrike --- Perhaps these are separate bugs, but: 1) gcc.dg/analyzer/pipe-manpages.c will need similar improvements 2) gcc.dg/analyzer/pipe-void-return.c passes with an incorrect declaration for pipe(), implying that we won't test whether it captures using uninitialized file descriptors when _pipe() fails
[Bug analyzer/108709] New: FAIL: gcc.dg/analyzer/pipe-glibc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108709 Bug ID: 108709 Summary: FAIL: gcc.dg/analyzer/pipe-glibc.c Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- This test fails on Windows for lack of fork. It actually fails for not having pipe(), also, but _pipe() does the job well enough, so that fix is a simple #define. It is not very apparent what the test is doing, since it doesn't get executed and doesn't appear to have analyzer calls, but the following poor man's solution does result in a test that executes correctly on x86_64-redhat-linux (EL8) and x86_64-w64-mingw32 under Wine. git diff ../gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c diff --git a/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c b/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c index a8546ea9549..3b93212f56d 100644 --- a/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c +++ b/gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c @@ -30,6 +30,30 @@ write_to_pipe (int file) fclose (stream); } +#ifdef WIN32 +// Use native _pipe with a thread on windows, as forks don't exist +// This requires that the pipes remain open, so disable close() + +#include +#include +#define pipe(FD) _pipe(FD, 256, O_BINARY) +#define close(X) + +#include +#include +static __cdecl void +fake_fork (void * arg) +{ +int * mypipe = arg; +read_from_pipe (mypipe[0]); +} + +#define fork() _beginthread(fake_fork, 0, mypipe) +#define wait(X) WaitForSingleObject((void *)pid, INFINITE) +#else +#include +#endif + int main (void) { @@ -66,6 +90,7 @@ main (void) Close other end first. */ close (mypipe[0]); write_to_pipe (mypipe[1]); + wait(NULL); return EXIT_SUCCESS; } }
[Bug analyzer/108708] New: __analyzer_dump_named_constant fails with derived values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108708 Bug ID: 108708 Summary: __analyzer_dump_named_constant fails with derived values Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- The analyzer test fd-access-mode-target-headers.c fails on mingw-w64 due to the following: FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 55) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 56) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 57) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for excess errors) Excess errors: gcc-git/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c:55:3: warning: named constant 'O_ACCMODE' has unknown value gcc-git/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c:56:3: warning: named constant 'O_RDONLY' has unknown value gcc-git/gcc/testsuite/gcc.dg/analyzer/fd-access-mode-target-headers.c:57:3: warning: named constant 'O_WRONLY' has unknown value This fails, because on mingw-w64, we define these macros indirectly: #define _O_RDONLY 0x #define _O_WRONLY 0x0001 #define _O_RDWR 0x0002 #define _O_ACCMODE (_O_RDONLY|_O_WRONLY|_O_RDWR) ... #define O_RDONLY _O_RDONLY #define O_WRONLY _O_WRONLY #define O_ACCMODE _O_ACCMODE If I modify the test to do "#undef O_ACCMODE; #define O_ACCMODE 42", it works as expected (and the other tests in the testsuite that test this also pass). I didn't flag this as a testsuite issue, though, because it seems that the issue is within the ability of __analyzer_dump_named_constant() to handle a macro value that references another macro or is some other valid expression. I also don't think it's specific to Windows. Perhaps related is that these tests also fail: FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 19) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 27) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 32) FAIL: gcc.dg/analyzer/fd-access-mode-target-headers.c (test for warnings, line 39) I assume this is related to the analyzer not being able to deduce the permissions passed to open().
[Bug testsuite/107602] dump-noaddr testcases fail when running the testsuite with already built installed toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107602 --- Comment #2 from nightstrike --- Better link(In reply to nightstrike from comment #1) > Reverting 186d43a78e945ebe9fbe217fc341847af7f95d30 fixes this problem at > least for me Better link: r255433
[Bug testsuite/107602] dump-noaddr testcases fail when running the testsuite with already built installed toolchain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107602 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #1 from nightstrike --- Reverting 186d43a78e945ebe9fbe217fc341847af7f95d30 fixes this problem at least for me
[Bug testsuite/108675] FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675 --- Comment #8 from nightstrike --- (In reply to LIU Hao from comment #7) > (In reply to nightstrike from comment #5) > > (In reply to LIU Hao from comment #4) > > > Does it make any sense to remove `#include ` from > > > 'gcc.c-torture/execute/builtins/lib/fprintf.c' ? > > > > That will prevent the FILE type from existing, so the replacement functions > > won't compile. > > That file never uses any fields of `FILE` directly. `FILE*` is always passed > as a pointer to `vfprintf()`, so it is perfectly valid to declare > >typedef struct _iobuf FILE; > > or even > >int fprintf (void* fp, const char* fmt, ...); Removing "include stdio" and changing both FILE*'s to void*'s does in fact make the test pass. Is this an acceptable way to pass the test? diff --git a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c index 853a705e86d..75406298856 100644 --- a/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c +++ b/gcc/testsuite/gcc.c-torture/execute/builtins/lib/fprintf.c @@ -1,11 +1,11 @@ -#include +//#include #include extern void abort (void); extern int inside_main; __attribute__ ((__noinline__)) int -fprintf (FILE *fp, const char *string, ...) +fprintf (void *fp, const char *string, ...) { va_list ap; int r; @@ -22,7 +22,7 @@ fprintf (FILE *fp, const char *string, ...) /* Locking stdio doesn't matter for the purposes of this test. */ __attribute__ ((__noinline__)) int -fprintf_unlocked (FILE *fp, const char *string, ...) +fprintf_unlocked (void *fp, const char *string, ...) { va_list ap; int r;
[Bug testsuite/108675] FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675 --- Comment #5 from nightstrike --- (In reply to LIU Hao from comment #4) > Does it make any sense to remove `#include ` from > 'gcc.c-torture/execute/builtins/lib/fprintf.c' ? That will prevent the FILE type from existing, so the replacement functions won't compile.
[Bug testsuite/108675] FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675 --- Comment #2 from nightstrike --- (In reply to Richard Biener from comment #1) > These tests are known to be a bit awkwardly implemented to check for > optimizations done ... How would you do it if you were writing the test today? > There might be a better way to provide definitions of fprintf, but is it > possible to short-circuit those definitions in the stdio.h header with > some macro definition? And would that make the execution succeed? If I modify stdio.h to #if 0 the definitions, then at least 16 fprintf tests pass (that's the only one I modified). We don't currently provide a macro mechanism to disable these, though. @jon_y, is this a reasonable workaround? (Ideally, fixing the test would happen instead, but if it's desirable that the headers can optionally define *printf outside of the testsuite, then we should entertain that as well).
[Bug testsuite/108675] New: FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108675 Bug ID: 108675 Summary: FAIL: gcc.c-torture/execute/builtins/*printf.c when stdio.h includes definitions Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Failing tests: gcc.c-torture/execute/builtins/printf.c gcc.c-torture/execute/builtins/fprintf.c gcc.c-torture/execute/builtins/sprintf.c On mingw-w64, the gcc.c-torture/execute/builtins/*printf.c tests fail. We include definitions of various functions in stdio.h instead of just declarations, leading to redefinition errors. For example, https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-headers/crt/stdio.h: __mingw_ovr __attribute__((__format__ (gnu_printf, 2, 3))) __MINGW_ATTRIB_NONNULL(2) int fprintf (FILE *__stream, const char *__format, ...) { int __retval; __builtin_va_list __local_argv; __builtin_va_start( __local_argv, __format ); __retval = __mingw_vfprintf( __stream, __format, __local_argv ); __builtin_va_end( __local_argv ); return __retval; } This causes the test to fail to compile at all optimization levels: gcc.c-torture/execute/builtins/lib/fprintf.c:8:1: error: redefinition of 'fprintf' mingw13/x86_64-w64-mingw32/include/stdio.h:357:5: note: previous definition of 'fprintf' with type 'int(FILE *, const char *, ...)' {aka 'int(struct _iobuf *, const char *, ...)'} The tests were originally added in r38065, r38788, and r48335. They were later moved in r84044 and tweaked a bit. Is there a better way to verify that the builtin was used instead of mingw version?
[Bug target/90826] Weak symbol does not work reliably on windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90826 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #3 from nightstrike --- See also: https://sourceware.org/bugzilla/show_bug.cgi?id=9687
[Bug testsuite/108427] New: bitfield tests fail with missing warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108427 Bug ID: 108427 Summary: bitfield tests fail with missing warnings Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Both bitfield-3.m and bitfield-5.m appear to fail for the same reason on x86_64-w64-mingw32 (cross compiled from linux, if it matters). The tests each contain multiple tests for warnings, only one of which is missing in each case: PASS: objc.dg/bitfield-3.m -fgnu-runtime (test for warnings, line 20) FAIL: objc.dg/bitfield-3.m -fgnu-runtime (test for warnings, line 27) PASS: objc.dg/bitfield-3.m -fgnu-runtime (test for warnings, line 32) PASS: objc.dg/bitfield-3.m -fgnu-runtime (test for warnings, line 33) PASS: objc.dg/bitfield-3.m -fgnu-runtime (test for excess errors) PASS: objc.dg/bitfield-3.m -fgnu-runtime execution test PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 24) PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 33) FAIL: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 40) PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 52) PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 57) PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 70) PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 74) PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 75) PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for warnings, line 76) PASS: objc.dg/bitfield-5.m -fgnu-runtime (test for excess errors) There are similar tests and failures for objc++, but maybe these are supposed to be XFAIL'd due to PR23610: PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime (test for warnings, line 21) PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime (test for warnings, line 33) PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime PR23610 at line 53 (test for bogus messages, line ) PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime PR23610 at line 55 (test for bogus messages, line 28) FAIL: obj-c++.dg/bitfield-4.mm -fgnu-runtime PR23610 at line 56 (test for bogus messages, line 34) PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime (test for excess errors) PASS: obj-c++.dg/bitfield-4.mm -fgnu-runtime execution test PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime (test for warnings, line 26) PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime (test for warnings, line 29) PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime (test for warnings, line 76) PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 118 (test for bogus messages, line ) PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 119 (test for bogus messages, line 42) FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 120 (test for bogus messages, line 45) FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 121 (test for bogus messages, line 59) FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 122 (test for bogus messages, line 62) FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 123 (test for bogus messages, line 77) FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime PR23610 at line 124 (test for bogus messages, line 78) PASS: obj-c++.dg/bitfield-1.mm -fgnu-runtime (test for excess errors) bitfield-3.m: @interface Derived: Base { signed e: 5; int f: 4; enum Enum g: 3; } /* { dg-warning "padding struct size to alignment boundary" } */ @end bitfield-5.m: @interface Derived: Base { @public signed e: 5; unsigned f: 4; enum Enum g: 3; } /* { dg-warning "padding struct size to alignment boundary" } */ @end
[Bug d/108408] New: libphobos: Support building on *-*-cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108408 Bug ID: 108408 Summary: libphobos: Support building on *-*-cygwin Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: nightstrike at gmail dot com Target Milestone: --- See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99794 for reference. This PR is tracking the state of building libphobos on cygwin using 11.3, the last compiler that can be bootstrapped natively. Currently, it fails due to missing definitions for FILE, snprintf, time_t, and clock_t. I'm currently trying to add them to libphobos/libdruntime/core/stdc/stdio.d, because the path for CRuntime_Newlib is currently missing. I seem to be falling down a rabbit hole of needing to define struct after struct, so I'm trying to gather the work here in hopes that some kind soul can help. I should clarify that I'm unfamiliar with D, so what I'm putting here definitely needs someone with experience to finish the work. My hope is to just get it far enough along that others can do so. Whoever put in the gcc warning that automatically converts function pointers for you, please accept my thanks! I started by lifting the structure definitions from cygwin's newlib, which unfortunately have quite a few conditional components. I don't know how important this is if for instance a structure has: struct S { #ifdef A int a; #else void * b; }; or some variation of all manner of conditions that change the struct layout and the total size. Guidance as to whether this is the right approach or a total waste of time would be appreciated :). With what I have so far, I'm down to just the following: /cygdrive/k/gcc/src/gcc-git/libphobos/libdruntime/core/sys/posix/stdc/time.d:52:15: error: module core.sys.posix.sys.types import 'time_t' not found 52 | public import core.sys.posix.sys.types : time_t, clock_t; | ^ /cygdrive/k/gcc/src/gcc-git/libphobos/libdruntime/core/sys/posix/stdc/time.d:52:15: error: module core.sys.posix.sys.types import 'clock_t' not found 52 | public import core.sys.posix.sys.types : time_t, clock_t; | ^ /cygdrive/k/gcc/src/gcc-git/libphobos/libdruntime/core/stdc/stdio.d:1514:9: error: undefined identifier 'fpos_t', did you mean alias '_fpos_t'? 1514 | int fgetpos(FILE* stream, scope fpos_t * pos); | ^ /cygdrive/k/gcc/src/gcc-git/libphobos/libdruntime/core/stdc/stdio.d:1516:9: error: undefined identifier 'fpos_t', did you mean alias '_fpos_t'? 1516 | int fsetpos(FILE* stream, scope const fpos_t* pos); | ^ ../../../../libphobos/libdruntime/core/demangle.d:2615:16: error: module core.stdc.stdio import 'snprintf' not found, did you mean function 'core.stdc.stdio.sprintf'? 2615 | import core.stdc.stdio : snprintf; |^ This is the diff so far: diff --git a/libphobos/libdruntime/core/stdc/stdio.d b/libphobos/libdruntime/core/stdc/stdio.d index c76b922a3eb..52bcc9d7cdd 100644 --- a/libphobos/libdruntime/core/stdc/stdio.d +++ b/libphobos/libdruntime/core/stdc/stdio.d @@ -397,6 +397,196 @@ else version (CRuntime_Microsoft) /// alias shared(_iobuf) FILE; } +else version (CRuntime_Newlib) +{ +alias long _off64_t; +alias long _fpos_t; +alias long _fpos64_t; +alias int _float_t; + +struct __sbuf { +char* _base; +int _size; +} + +struct _mbstate_t { +int _count; +union { +dchar _wch; +char[4] _wchb; +} +} + +struct _rand48 { +ushort[3] _seed; +ushort[3] _mult; +ushort _add; +} + +struct __tm { +int __tm_sec; +int __tm_min; +int __tm_hour; +int __tm_mday; +int __tm_mon; +int __tm_year; +int __tm_wday; +int __tm_yday; +int __tm_isdst; +} + +struct __lc_cats { +const void* ptr; +char*buf; +} + +struct lconv { +char* decimal_point; +char* thousands_sep; +char* grouping; +char* int_curr_symbol; +char* currency_symbol; +char* mon_decimal_point; +char* mon_thousands_sep; +char* mon_grouping; +char* positive_sign; +char* negative_sign; +char int_frac_digits; +char frac_digits; +char p_cs_precedes; +char p_sep_by_space; +char n_cs_precedes; +char n_sep_by_space; +char p_sign_posn; +char n_sign_posn; +char int_n_cs_precedes; +char int_n_sep_by_space; +char int_n_sign_posn; +char int_p_cs_precedes; +char int_p
[Bug middle-end/108300] `abort()` macro cause bootstrap failure on *-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #15 from nightstrike --- Someone on irc (jakub?) suggested just changing all of the aborts to gcc_unreachable. Is that a viable option?
[Bug target/82028] Windows x86_64 should not pass float aggregates in xmm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82028 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #5 from nightstrike --- (In reply to jon_y from comment #4) > I can't seem to change the bug status to confirmed. "NEW" is confirmed
[Bug target/90256] Optimizer with interrupt routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90256 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #2 from nightstrike --- This is not target specific (or at least it also happens on x86_64-pc-linux).
[Bug d/99794] libphobos: Support building on *-*mingw*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99794 --- Comment #3 from nightstrike --- Hm, looks like it *IS* in 11. I was confused by the PR being open and the version stating 11, thinking that it still wasn't applied. So the remaining issues then are building on cygwin. But at least on a linux to mingw cross, the testsuite passes with only 33 fails.
[Bug d/99794] libphobos: Support building on *-*mingw*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99794 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #2 from nightstrike --- Hoping this can be backported to 11 so that we can easily bootstrap later versions. Meanwhile, will this also fix the build errors on cygwin, or if is specific to mingw?
[Bug testsuite/108204] pr84973-2.C fails with wrong error on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108204 --- Comment #4 from nightstrike --- (In reply to Richard Biener from comment #3) > I'd suggest to add a dg-additional-options -fno-ms-extensions to the test > then. We certainly can (well, Jon can :P), but shouldn't the ms extensions ultimately be fixed to work right?
[Bug libstdc++/108332] dynamic link libstdc++ with win32 thread model's gcc for windows native toolchain would cause .rdata_r: section below image base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108332 nightstrike changed: What|Removed |Added CC||10walls at gmail dot com, ||nightstrike at gmail dot com --- Comment #5 from nightstrike --- (In reply to cqwrteur from comment #4) > (In reply to Andrew Pinski from comment #3) > > cygwin was improved here: > > https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git; > > h=801120c1f402f9b0f72b5a231bf9e1cf82614cac > > > > It might be the case mingw linker script is broken > > This is mingw-w64, not newlib-cygwin I think he's suggesting that we have to apply the same solution to mingw that Corinna applied to Cygwin.
[Bug testsuite/108192] g++.dg/cet-notrack-1.C searching for wrong function on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192 --- Comment #3 from nightstrike --- Created attachment 54209 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54209&action=edit Patch to change printf to puts so it works everywhere
[Bug testsuite/108152] gcc.dg/pr71558.c fails for LLP64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108152 nightstrike changed: What|Removed |Added CC||10walls at gmail dot com --- Comment #3 from nightstrike --- (In reply to Andrew Pinski from comment #1) > { dg-options "" } So just to be pedantic (pun intended!), the options currently in use are: -fdiagnostics-plain-output -ansi -pedantic-errors If we use dg-options "", both -ansi and -pedantic-errors are removed. -fdiagnostics-plain-output stays. Is this ok?
[Bug preprocessor/107974] compiler can't find source file in path that is longer than 255 characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107974 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #7 from nightstrike --- Someone with build system experience could modify the build of the toolchain binaries to include a call to windres to add the manifest. This would just be gcc itself and not what gcc produces. I guess maybe the binutils executables would benefit also.
[Bug testsuite/108150] gcc.dg/attr-aligned.c fails with incorrect max alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108150 nightstrike changed: What|Removed |Added CC||10walls at gmail dot com --- Comment #2 from nightstrike --- It occurs to me, if GCC already internally knows the max alignment (since it's outputting it in the warning message), why do we need to have such complicated preprocessor magic to guess at what the alignment is? Would it be easier to have GCC just define __GCC_MAX_ALIGNMENT__ or something similar for all targets, and then use that in the test?
[Bug target/102993] -fcf-protection=full produces segfaulting code when targeting 32-bit x86 (i686)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102993 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #9 from nightstrike --- Maybe it's time to disable sjlj support on windows. dwarf or SEH is better on average.
[Bug target/103327] Do not search MINGW in the search dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103327 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #2 from nightstrike --- This is intentional, and goes back to at least gcc 3. The idea here is that the path /mingw, which has to be in your sysroot and is usually a symlink to $target, is the place to find the mingw-w64 headers and import libraries. This is the equivalent of /usr/local in a posix environment, which doesn't exist for this target.
[Bug bootstrap/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427 --- Comment #11 from nightstrike --- Possible duplicate of PR39947
[Bug bootstrap/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #10 from nightstrike --- (In reply to cqwrteur from comment #5) > I think the copy to bin behavior should be removed. It should be just like > normal linux distribution. 64 bit dlls in lib. 32 bit dlls in lib32. This is a feature of Windows. Windows will find dlls in PATH, not in lib directories. Multilib toolchains do face issues with versioned runtime libraries. You can try configuring with --enable-version-specific-runtime-libs. Generally speaking, it's easier to just build two separate toolchains than to try getting multilib to work. I made the mistake of pushing for multilib to be enabled by default, and we never got it working quite well. Anyway, I don't think this is a bug as stated.
[Bug c++/106395] [12/13 regression] [mingw] "redeclared without dllimport attribute: previous dllimport ignored" on C++ friend since r12-299-ga0fdff3cf33f72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106395 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #4 from nightstrike --- This appears to be fixed in GCC 13
[Bug libstdc++/108210] error: 'mutex' does not name a type; did you mean 'minutes'? for x86_64-w64-mingw32 target with win32 thread model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108210 nightstrike changed: What|Removed |Added CC||i.nixman at autistici dot org, ||nightstrike at gmail dot com --- Comment #2 from nightstrike --- Is this before or after this patch set was applied? https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609116.html
[Bug c++/108207] ICE in testcase g++.dg/other/ptrmem8.C on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108207 --- Comment #1 from nightstrike --- Ah, Andrew, before you beat me to it... this doesn't ICE if you pass -fno-ms-extensions, and it does ICE on Linux if you pass -fms-extensions
[Bug c++/108207] New: ICE in testcase g++.dg/other/ptrmem8.C on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108207 Bug ID: 108207 Summary: ICE in testcase g++.dg/other/ptrmem8.C on mingw Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- All variants of this test fail (98, 14, 17, 20) // Target: x86_64-w64-mingw32 // Configured with: ../configure --disable-nls --with-sysroot=/tmp/rtmingw --target=x86_64-w64-mingw32 --disable-multilib --enable-languages=c,c++,fortran,lto,objc,obj-c++,m2,rust // Thread model: win32 // Supported LTO compression algorithms: zlib zstd // gcc version 13.0.0 20221222 (experimental) (GCC) bbe04bade0cc3b17e62c2af3d89b899367e7d2d1 g++.dg/other/ptrmem8.C: In function 'void foo(void (A::*)())': g++.dg/other/ptrmem8.C:9:9: internal compiler error: in build_ptrmemfunc, at cp/typeck.cc:10015 0x7f38c0 build_ptrmemfunc(tree_node*, tree_node*, int, bool, int) ../../gcc/cp/typeck.cc:10015 0xc643bb cp_build_addr_expr_1 ../../gcc/cp/typeck.cc:7241 0xc64704 cp_build_addr_expr_strict ../../gcc/cp/typeck.cc:7269 0xc64704 build_x_unary_op(unsigned int, tree_code, cp_expr, tree_node*, int) ../../gcc/cp/typeck.cc:6890 0xb9b7c3 cp_parser_unary_expression ../../gcc/cp/parser.cc:9039 0xb688bc cp_parser_binary_expression ../../gcc/cp/parser.cc:10101 0xb69612 cp_parser_assignment_expression ../../gcc/cp/parser.cc:10444 0xb6ba73 cp_parser_expression ../../gcc/cp/parser.cc:10614 0xb6fa07 cp_parser_expression_statement ../../gcc/cp/parser.cc:12758 0xb7aced cp_parser_statement ../../gcc/cp/parser.cc:12538 0xb7bfdd cp_parser_statement_seq_opt ../../gcc/cp/parser.cc:12909 0xb7c0b7 cp_parser_compound_statement ../../gcc/cp/parser.cc:12861 0xb9ea55 cp_parser_function_body ../../gcc/cp/parser.cc:25280 0xb9ea55 cp_parser_ctor_initializer_opt_and_function_body ../../gcc/cp/parser.cc:25331 0xba09fe cp_parser_function_definition_after_declarator ../../gcc/cp/parser.cc:31942 0xba1eb0 cp_parser_function_definition_from_specifiers_and_declarator ../../gcc/cp/parser.cc:31859 0xba1eb0 cp_parser_init_declarator ../../gcc/cp/parser.cc:22734 0xba928e cp_parser_single_declaration ../../gcc/cp/parser.cc:32459 0xba94b4 cp_parser_template_declaration_after_parameters ../../gcc/cp/parser.cc:32012 0xba9d40 cp_parser_explicit_template_declaration ../../gcc/cp/parser.cc:32285 Preprocessed source is as you might expect, given the lack of includes: struct A {}; template void foo(void (A::* f)()) { A a; &(a.*f); } template void bar(void (A::* f)()) { A *p; &(p->*f); }
[Bug c++/108204] pr84973-2.C fails with wrong error on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108204 --- Comment #2 from nightstrike --- (In reply to Andrew Pinski from comment #1) > Try with -fno-ms-extensions or try -fms-extension on Linux. Hey, we have a winner! -fms-extension on Linux results in the bad error, and -fno-ms-extensions on mingw results in the good one!
[Bug c++/108204] New: pr84973-2.C fails with wrong error on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108204 Bug ID: 108204 Summary: pr84973-2.C fails with wrong error on mingw Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- All of the pr84973-2.C tests fail on mingw. They give the output: g++.dg/template/pr84973-2.C: In instantiation of 'void a()::c::b() [with int = 0]': g++.dg/template/pr84973-2.C:7:3: required from 'void a() [with int = 0]' g++.dg/template/pr84973-2.C:12:7: required from here g++.dg/template/pr84973-2.C:5:20: error: statement cannot resolve address of overloaded function or outside the testsuite for slightly different formatting: $ x86_64-w64-mingw32-g++ -c a.cc a.cc: In instantiation of 'void a()::c::b() [with int = 0]': a.cc:5:11: required from 'void a() [with int = 0]' a.cc:10:8: required from here a.cc:3:38: error: statement cannot resolve address of overloaded function 3 | void b() try { b; } catch (short) { // { dg-error "invalid use" } | ^ On linux, however, the output is different: a.cc: In instantiation of 'void a()::c::b() [with int = 0]': a.cc:5:11: required from 'void a() [with int = 0]' a.cc:10:8: required from here a.cc:3:38: error: invalid use of non-static member function 'void a()::c::b() [with int = 0]' 3 | void b() try { b; } catch (short) { // { dg-error "invalid use" } | ^ a.cc:3:28: note: declared here 3 | void b() try { b; } catch (short) { // { dg-error "invalid use" } |^
[Bug c++/108203] New: Format string checking with __USE_MINGW_ANSI_STDIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108203 Bug ID: 108203 Summary: Format string checking with __USE_MINGW_ANSI_STDIO Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Circa v4.5, some mingw-w64 users discovered an issue with printf functions and g++. Addressing this resulted in a kludge on the mingw-w64 headers side, but this should have been documented here so that we can remove the kludge and have a better coordination between projects. Original mail thread describing the problem: https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/4F05E61C.6010506%40t-online.de/#msg28632591 Bug report that came from it: https://sourceforge.net/p/mingw-w64/bugs/292/ Header change from fixing the bug report: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/280b5f973e/ This commit might potentially be related: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/1ed6dcc2a19c1aeac5dd4e6530af899fd8d95dbb/ +/* Override __builtin_printf-routines ... Kludge for libstdc++ ...*/ +#define __builtin_vsnprintf __mingw_vsnprintf +#define __builtin_vsprintf __mingw_vsprintf I hope with this PR, we can better coordinate and make both sides better :)
[Bug tree-optimization/101854] [11 Regression] Invalid warning -Wstringop-overflow wrong argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101854 --- Comment #11 from nightstrike --- (In reply to Martin Sebor from comment #9) > Fixed for GCC 12. The patch is far too intrusive to backport but the > following should fix the problem in GCC 11: Would you mind applying it to 11? Thanks! Also, I think in your diff below, there's "// A nonnull" that should be "/* A nonnull"... / to * > diff --git a/gcc/calls.c b/gcc/calls.c > index fcb0d6dec69..f116923c890 100644 > --- a/gcc/calls.c > +++ b/gcc/calls.c > @@ -2295,14 +2295,15 @@ initialize_argument_information (int num_actuals > ATTRIBUTE_UNUSED, > operand for later processing. */ >if (attr_access *access = rdwr_idx.get (argpos)) > { > + int idx = i - !!struct_value_addr_value; > if (POINTER_TYPE_P (type)) > { > - access->ptr = args[i].tree_value; > + access->ptr = args[idx].tree_value; > // A nonnull ACCESS->SIZE contains VLA bounds. */ > } > else > { > - access->size = args[i].tree_value; > + access->size = args[idx].tree_value; > gcc_assert (access->ptr == NULL_TREE); > } > }
[Bug testsuite/108192] g++.dg/cet-notrack-1.C searching for wrong function on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192 --- Comment #2 from nightstrike --- (In reply to H.J. Lu from comment #1) > Since Windows doesn't support IBT, this test can be limited to Linux. I don't know what IBT is, but if I change the two printf's to puts(), the tests pass. So, maybe they don't have to be skipped?
[Bug testsuite/108192] New: g++.dg/cet-notrack-1.C searching for wrong function on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108192 Bug ID: 108192 Summary: g++.dg/cet-notrack-1.C searching for wrong function on mingw Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Created attachment 54139 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54139&action=edit cet-notrack-1.s g++.dg/cet-notrack-1.C Tries to find 'call puts()' in the asm after calling printf() on the c++ side. On Mingw, we do magic things with converting printf() into __mingw_ variants to support MS style printf and other things. So the assembler dump on mingw results in a call to __mingw_vfprintf in this particular case. It would likely be possible to fix the testcase by searching for "call __mingw_*printf" or something, but I'm curious if this is really a case of a missed optimization. The strings in question are simple string literals, so we don't care about mingw or ms special versions of printf, and a call to puts should be fine. I don't know if this testcase is specifically trying to validate that optimization, but it at least indirectly revealed it. Asm attached.
[Bug testsuite/108190] g++.target/i386/*pr54700*.C testcases fail on x86_64-mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190 --- Comment #5 from nightstrike --- Created attachment 54138 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54138&action=edit avx512vl-pr54700-1b.s
[Bug testsuite/108190] g++.target/i386/*pr54700*.C testcases fail on x86_64-mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190 --- Comment #4 from nightstrike --- Created attachment 54137 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54137&action=edit avx512vl-pr54700-1a.s
[Bug testsuite/108190] g++.target/i386/*pr54700*.C testcases fail on x86_64-mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190 --- Comment #3 from nightstrike --- Created attachment 54136 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54136&action=edit avx2-pr54700-1.s
[Bug testsuite/108190] Various testsuite asm fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190 --- Comment #1 from nightstrike --- Created attachment 54135 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54135&action=edit avx-pr54700-1.s
[Bug testsuite/108190] New: Various testsuite asm fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108190 Bug ID: 108190 Summary: Various testsuite asm fails Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Created attachment 54134 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54134&action=edit asm output 1 The following are a collection of failures from running PR54700 tests on a linux to mingw cross compiler under Wine 7.20: FAIL: g++.target/i386/sse4_1-pr54700-1.C scan-assembler-not pcmpgt[bdq] FAIL: g++.target/i386/sse4_1-pr54700-1.C scan-assembler-times pblendvb 2 FAIL: g++.target/i386/sse4_1-pr54700-1.C scan-assembler-times blendvps 4 FAIL: g++.target/i386/sse4_1-pr54700-1.C scan-assembler-times blendvpd 4 FAIL: g++.target/i386/avx-pr54700-1.C scan-assembler-not vpcmpgt[bdq] FAIL: g++.target/i386/avx-pr54700-1.C scan-assembler-times vpblendvb 2 FAIL: g++.target/i386/avx-pr54700-1.C scan-assembler-times vblendvps 4 FAIL: g++.target/i386/avx-pr54700-1.C scan-assembler-times vblendvpd 4 FAIL: g++.target/i386/avx2-pr54700-1.C scan-assembler-not vpcmpgt[bdq] FAIL: g++.target/i386/avx2-pr54700-1.C scan-assembler-times vpblendvb 2 FAIL: g++.target/i386/avx2-pr54700-1.C scan-assembler-times vblendvps 4 FAIL: g++.target/i386/avx2-pr54700-1.C scan-assembler-times vblendvpd 4 FAIL: g++.target/i386/avx512vl-pr54700-1a.C scan-assembler-times vpblendvb 2 FAIL: g++.target/i386/avx512vl-pr54700-1b.C scan-assembler-times pblendvb 2 I don't know if it's helpful, but these are the /proc/cpuinfo flags on the cpus running under wine on an Intel(R) Xeon(R) Gold 6230: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch _perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single ssbd mba ibrs ibpb stibp ibrs_enhanced fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_ mbm_total cqm_mbm_local dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req pku ospke avx512_vnni md_clear flush_l1d arch_capabilities
[Bug testsuite/108152] gcc.dg/pr71558.c fails for LLP64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108152 --- Comment #2 from nightstrike --- (In reply to Andrew Pinski from comment #1) > { dg-options "" } That would remove every option, no? Do others matter, like -pedantic, or whatever else is there?
[Bug testsuite/108150] gcc.dg/attr-aligned.c fails with incorrect max alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108150 --- Comment #1 from nightstrike --- Ok, that was dumb.. WINT_MAX is wide int max... hah. So maybe test for __CYGWIN__ || __WIN32__
[Bug testsuite/108161] New: gcc.dg/ipa/pr96040.c fails with incorrect size_t assumption (snprintf, strspn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108161 Bug ID: 108161 Summary: gcc.dg/ipa/pr96040.c fails with incorrect size_t assumption (snprintf, strspn) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- gcc.dg/ipa/pr96040.c assumes that size_t is unsigned long, which it isn't for LLP64. The following definitions are therefor incorrect: int snprintf(char *, unsigned long, const char *, ...); unsigned long strspn(const char *, const char *); Changing "unsigned long" in both instances to "__SIZE_TYPE__" makes the test pass: int snprintf(char *, __SIZE_TYPE__, const char *, ...); __SIZE_TYPE__ strspn(const char *, const char *); However, it's also possible, and perhaps more maintainable, to just use __builtin_*, or to include and . Both of the following options work, though there are many ways to skin this cat: diff --git a/gcc/testsuite/gcc.dg/ipa/pr96040.c b/gcc/testsuite/gcc.dg/ipa/pr96040.c index af7e9c4ed94..9c9b76269a6 100644 --- a/gcc/testsuite/gcc.dg/ipa/pr96040.c +++ b/gcc/testsuite/gcc.dg/ipa/pr96040.c @@ -3,8 +3,8 @@ int puts(const char *); -int snprintf(char *, unsigned long, const char *, ...); -unsigned long strspn(const char *, const char *); +int snprintf(char *, __SIZE_TYPE__, const char *, ...); +__SIZE_TYPE__ strspn(const char *, const char *); struct TValue { union { diff --git a/gcc/testsuite/gcc.dg/ipa/pr96040.c b/gcc/testsuite/gcc.dg/ipa/pr96040.c index af7e9c4ed94..2c8d405ff9b 100644 --- a/gcc/testsuite/gcc.dg/ipa/pr96040.c +++ b/gcc/testsuite/gcc.dg/ipa/pr96040.c @@ -3,8 +3,8 @@ int puts(const char *); -int snprintf(char *, unsigned long, const char *, ...); -unsigned long strspn(const char *, const char *); +#define snprintf __builtin_snprintf +#define strspn __builtin_strspn struct TValue { union {
[Bug testsuite/108160] gcc.dg/format/ms_attr-3.c testsuite failure, missed update from r9-4163-g1d24950977c730
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108160 --- Comment #1 from nightstrike --- It looks like the other testsuite changes (attr-8.c, the objc/c++ tests, etc.) should be evaluated and ported over also, so this isn't a complete fix. Alternatively, maybe this would scale better in the future if the ms_ tests were integrated into the non-ms_ tests, with a macro to set the format checking attribute between gnu_attr_printf and ms_printf.
[Bug testsuite/108160] New: gcc.dg/format/ms_attr-3.c testsuite failure, missed update from r9-4163-g1d24950977c730
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108160 Bug ID: 108160 Summary: gcc.dg/format/ms_attr-3.c testsuite failure, missed update from r9-4163-g1d24950977c730 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Created attachment 54120 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54120&action=edit Suggested changes r9-4163-g1d24950977c730 changed the output of certain messages and adjusted the non-ms-printf cases, but missed the windows version of attr-3.c. FAIL: gcc.dg/format/ms_attr-3.cbad number (test for errors, line 44) FAIL: gcc.dg/format/ms_attr-3.cbad number (test for errors, line 45) FAIL: gcc.dg/format/ms_attr-3.cbad format_arg number (test for errors, line 47) FAIL: gcc.dg/format/ms_attr-3.cformat int string (test for errors, line 59) FAIL: gcc.dg/format/ms_attr-3.csigned char string (test for errors, line 60) FAIL: gcc.dg/format/ms_attr-3.cunsigned char string (test for errors, line 61) FAIL: gcc.dg/format/ms_attr-3.cnot ... (test for errors, line 63) FAIL: gcc.dg/format/ms_attr-3.cformat_arg int string (test for errors, line 66) FAIL: gcc.dg/format/ms_attr-3.cformat_arg signed char string (test for errors, line 67) FAIL: gcc.dg/format/ms_attr-3.cformat_arg unsigned char string (test for errors, line 68) FAIL: gcc.dg/format/ms_attr-3.c(test for excess errors) Excess errors: gcc.dg/format/ms_attr-3.c:44:1: warning: 'format' attribute argument 2 value 'foo' is not an integer constant [-Wattributes] gcc.dg/format/ms_attr-3.c:45:1: warning: 'format' attribute argument 3 value 'foo' is not an integer constant [-Wattributes] gcc.dg/format/ms_attr-3.c:47:1: warning: 'format_arg' attribute argument value 'foo' is not an integer constant [-Wattributes] gcc.dg/format/ms_attr-3.c:59:1: error: 'format' attribute argument 2 value '1' refers to parameter type 'int' gcc.dg/format/ms_attr-3.c:60:1: error: 'format' attribute argument 2 value '1' refers to parameter type 'signed char *' gcc.dg/format/ms_attr-3.c:61:1: error: 'format' attribute argument 2 value '1' refers to parameter type 'unsigned char *' gcc.dg/format/ms_attr-3.c:63:1: error: 'format' attribute argument 3 value '2' does not refer to a variable argument list gcc.dg/format/ms_attr-3.c:66:1: error: 'format_arg' attribute argument value '1' refers to parameter type 'int' gcc.dg/format/ms_attr-3.c:67:1: error: 'format_arg' attribute argument value '1' refers to parameter type 'signed char *' gcc.dg/format/ms_attr-3.c:68:1: error: 'format_arg' attribute argument value '1' refers to parameter type 'unsigned char *' Applying the changes to attr-3.c directly to ms_attr-3.c isn't exactly right, though. First, gnu_attr_printf needs to change to ms_printf. Second, there are followup changes from r9-5404-g23db6ced33c245 to fix the remaining issues. The resulting diff is a bit big, so I uploaded suggested changes as an attachment.
[Bug testsuite/108159] gcc.dg/format/ms-format2.c fails due to warning message change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108159 --- Comment #1 from nightstrike --- Andrew pointed out that this is the better fix, and it does indeed work: diff --git a/gcc/testsuite/gcc.dg/format/ms-format2.c b/gcc/testsuite/gcc.dg/format/ms-format2.c index 5c950522a7c..9d21d108642 100644 --- a/gcc/testsuite/gcc.dg/format/ms-format2.c +++ b/gcc/testsuite/gcc.dg/format/ms-format2.c @@ -3,7 +3,7 @@ */ /* Origin: Kai Tietz */ /* { dg-do compile { target { *-*-mingw* } } } */ -/* { dg-options "-std=iso9899:1999 -pedantic -Wformat -Wno-pedantic-ms-format" } */ +/* { dg-options "-std=iso9899:1999 -pedantic -Wformat -Wno-pedantic-ms-format -ftrack-macro-expansion=0" } */ #define USE_SYSTEM_FORMATS #include "format.h"
[Bug testsuite/108159] New: gcc.dg/format/ms-format2.c fails due to warning message change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108159 Bug ID: 108159 Summary: gcc.dg/format/ms-format2.c fails due to warning message change Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- This is presumably a regression, as the test worked when it first went in. However, the warning message being tested for has since changed the line that gets reported: printf (XXX, p); /* { dg-warning "format" "bad argument types" } */ printf ("%I32x", f); /* { dg-warning "format" "bad argument types" } */ printf ("%I64x", d); /* { dg-warning "format" "bad argument types" } */ gcc.dg/format/ms-format2.c: In function 'foo': gcc.dg/format/ms-format2.c:12:13: warning: format '%I64x' expects argument of type 'long long unsigned int', but argument 2 has type 'void *' [-Wformat=] gcc.dg/format/ms-format2.c:20:11: note: in expansion of macro 'XXX' gcc.dg/format/ms-format2.c:12:18: note: format string is defined here gcc.dg/format/ms-format2.c:21:16: warning: format '%I32x' expects argument of type 'long unsigned int', but argument 2 has type 'double' [-Wformat=] gcc.dg/format/ms-format2.c:22:16: warning: format '%I64x' expects argument of type 'long long unsigned int', but argument 2 has type 'double' [-Wformat=] FAIL: gcc.dg/format/ms-format2.c -DWIDE bad argument types (test for warnings, line 20) PASS: gcc.dg/format/ms-format2.c -DWIDE bad argument types (test for warnings, line 21) PASS: gcc.dg/format/ms-format2.c -DWIDE bad argument types (test for warnings, line 22) FAIL: gcc.dg/format/ms-format2.c -DWIDE (test for excess errors) Excess errors: gcc.dg/format/ms-format2.c:12:13: warning: format '%I64x' expects argument of type 'long long unsigned int', but argument 2 has type 'void *' [-Wformat=] I assume the fix is to move the dg-warning to the macro definition line, but I don't know how to distinguish between the 32 and 64-bit cases in dejagnu. To be clear, the following change makes the test work for the 64-bit case: diff --git a/gcc/testsuite/gcc.dg/format/ms-format2.c b/gcc/testsuite/gcc.dg/format/ms-format2.c index 5c950522a7c..e56bfc4a9c4 100644 --- a/gcc/testsuite/gcc.dg/format/ms-format2.c +++ b/gcc/testsuite/gcc.dg/format/ms-format2.c @@ -9,7 +9,7 @@ #include "format.h" #ifdef _WIN64 -#define XXX "%I64x" +#define XXX "%I64x" /* { dg-warning "format" "bad argument types" } */ #else #define XXX "%I32x" #endif @@ -17,7 +17,7 @@ void foo (float f, double d, void *p) { - printf (XXX, p); /* { dg-warning "format" "bad argument types" } */ + printf (XXX, p); printf ("%I32x", f); /* { dg-warning "format" "bad argument types" } */ printf ("%I64x", d); /* { dg-warning "format" "bad argument types" } */ } But that won't address the 32-bit case. I suppose there's some other "{}" thing to put on both #define XXX lines to choose which architecture, but I don't know what that would be. Hopefully this is enough diagnosis for someone more knowledgeable to pick it up and run with it.
[Bug testsuite/108152] New: gcc.dg/pr71558.c fails for LLP64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108152 Bug ID: 108152 Summary: gcc.dg/pr71558.c fails for LLP64 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- gcc.dg/pr71558.c has the following lines: __SIZE_TYPE__ strlen (const char *); void *malloc (__SIZE_TYPE__); __SIZE_TYPE__ b = strlen (a); These are good in that they support LLP64 through size_t, however they fail because this test case is compiled with -ansi. When using -ansi, the following warnings appear: gcc.dg/pr71558.c:6:1: error: ISO C90 does not support 'long long' [-Wlong-long] gcc.dg/pr71558.c:7:1: error: ISO C90 does not support 'long long' [-Wlong-long] gcc.dg/pr71558.c:14:1: error: ISO C90 does not support 'long long' [-Wlong-long] And of course, on LLP64 systems, __SIZE_TYPE__ is in fact a long long. Hopefully, -ansi can just be removed from the compile options, although I don't know how to do that.
[Bug testsuite/108151] New: gcc.dg/pr64536.c stores pointers in a long, broken for llp64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108151 Bug ID: 108151 Summary: gcc.dg/pr64536.c stores pointers in a long, broken for llp64 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- gcc/testsuite/gcc.dg/pr64536.c contains lines such as the following: struct S { long q; } *h; long a, b, g, j, k, *c, *d, *e, *f, *i; i = (long *) (h->q = *f); *c++ = (long) f; These lines were added with the following commit: adfac8dfed7b (Jakub Jelinek 2015-01-09 22:17:10 +0100 56) This has the erroneous assumption that a long can hold a pointer. This should probably just use intptr_t or __INTPTR_TYPE__ for all occurrences. Changing q to be an __INTPTR_TYPE__ and both casts of f to be likewise makes the test pass. Note: I didn't put mingw in the target field, because this affects any LLP64 platform.
[Bug c/108150] New: gcc.dg/attr-aligned.c fails with incorrect max alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108150 Bug ID: 108150 Summary: gcc.dg/attr-aligned.c fails with incorrect max alignment Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- On Windows targets, the max alignment is 8192. However, this test winds up assuming the max alignment is much larger, causing multiple failures. Specifically, the test is getting into: #elif __powerpc64__ || __x86_64__ /* Is this processor- or operating-system specific? */ # define ALIGN_MAX_STATIC ALIGN_MAX_HARD and ALIGN_MAX_HARD is set to: /* The maximum alignment GCC can handle. */ #define ALIGN_MAX_HARD 0x1000 If it fell through to: #else /* Guaranteed to be accepted regardless of the target. */ # define ALIGN_MAX_STATIC __BIGGEST_ALIGNMENT__ that would still be wrong, as __BIGGEST_ALIGNMENT__ is set to 16. Another case that checks for Windows and sets it to 8192 should fix it. The check should cover all windows platforms, including cygwin and msys. Technically, msys defines both __MSYS__ and __CYGWIN__, so testing for __CYGWIN__ || __MINGW32__ || __MINGW64__ would cover all bases. Alternatively, and potentially easier, __WINT_MAX__ is defined on all targets, so you could just test for that. Someone will likely want to do it perhaps in a more sophisticated way, or be more obvious about the macros being tested if WINT_MAX is an obscure choice, or some other reason. However, the following change works: diff --git a/gcc/testsuite/gcc.dg/attr-aligned.c b/gcc/testsuite/gcc.dg/attr-aligned.c index a2e11c96180..a56973c99b4 100644 --- a/gcc/testsuite/gcc.dg/attr-aligned.c +++ b/gcc/testsuite/gcc.dg/attr-aligned.c @@ -22,6 +22,9 @@ # define ALIGN_MAX_STATIC 2 /* Work around a pdp11 ICE (see PR target/87821). */ # define ALIGN_MAX_AUTO(ALIGN_MAX_HARD >> 14) +#elif __WINT_MAX__ +# define ALIGN_MAX_STATIC 8192 +# define ALIGN_MAX_AUTO8192 #elif __powerpc64__ || __x86_64__ /* Is this processor- or operating-system specific? */ # define ALIGN_MAX_STATIC ALIGN_MAX_HARD For reference, these are the excess errors: gcc/testsuite/gcc.dg/attr-aligned.c:65:1: error: requested alignment '268435456' exceeds object file maximum 8192 gcc/testsuite/gcc.dg/attr-aligned.c:66:1: error: requested alignment '268435456' exceeds object file maximum 8192 gcc/testsuite/gcc.dg/attr-aligned.c:67:1: error: requested alignment '268435456' exceeds object file maximum 8192 gcc/testsuite/gcc.dg/attr-aligned.c:68:1: error: requested alignment '268435456' exceeds object file maximum 8192 gcc/testsuite/gcc.dg/attr-aligned.c:70:1: error: static assertion failed gcc/testsuite/gcc.dg/attr-aligned.c:71:1: error: static assertion failed gcc/testsuite/gcc.dg/attr-aligned.c:72:1: error: static assertion failed gcc/testsuite/gcc.dg/attr-aligned.c:73:1: error: static assertion failed gcc/testsuite/gcc.dg/attr-aligned.c:61:22: error: alignment of 't_max' is greater than maximum object file alignment 8192 gcc/testsuite/gcc.dg/attr-aligned.c:78:47: error: alignment of 'alignas_sc_max' is greater than maximum object file alignment 8192 gcc/testsuite/gcc.dg/attr-aligned.c:79:40: error: alignment of 'alignas_c_max' is greater than maximum object file alignment 8192 gcc/testsuite/gcc.dg/attr-aligned.c:80:34: error: alignment of 'alignas_v_max' is greater than maximum object file alignment 8192 gcc/testsuite/gcc.dg/attr-aligned.c:99:31: error: alignment of 'aligned_st_max' is greater than maximum object file alignment 8192
[Bug c/107754] New: Confusing -Warray-bounds warning with strcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107754 Bug ID: 107754 Summary: Confusing -Warray-bounds warning with strcpy Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Metabug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=warray-bounds // Compile with GCC 12.2.0 with -O2: //warning: ‘strcpy’ offset 0 is out of the bounds [0, 0] [-Warray-bounds] // no warning without -O2 struct Inst; struct Class { int offset; }; static struct Class * classFoo; // No problem without static here struct Foo { unsigned int a; // no problem if commented out char bar[1024]; }; void setFoo(struct Inst * this, const char * value) { struct Foo * ptr = (struct Foo *)(this ? (((char *)this) + classFoo->offset) : 0); __builtin_strcpy(ptr->bar, value); } $ gcc-12 -c -O2 -Warray-bounds a.c -o /dev/null a.c: In function 'setFoo': a.c:19:4: warning: '__builtin_strcpy' offset 0 is out of the bounds [0, 0] [-Warray-bounds] 19 |__builtin_strcpy(ptr->bar, value); |^
[Bug c++/107531] List of references calls destructors, add warning?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107531 --- Comment #2 from nightstrike --- It looks like you're right. The root cause of the problem is that in my non-reduced case, I didn't have a copy constructor, but I had a non-default destructor that was releasing resources twice. So it's clearly my fault, I just kind of hoped the compiler could be a little more omniscient :) If a warning is not really possible here, then I guess this could be "closed invalid". Or maybe there are already PR's open to request a warning to remind you that you did something requiring a non-default copy constructor?
[Bug c++/107531] New: List of references calls destructors, add warning?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107531 Bug ID: 107531 Summary: List of references calls destructors, add warning? Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- The following code results in a destructor being calling twice: #include struct S { S() { __builtin_printf("ctor\n"); } ~S() { __builtin_printf("dtor\n"); } }; template void f(Args const & ... args) { for (auto const & s: { args... }) ; } int main() { S s; f(s); } $ ./a.out ctor dtor dtor Changing line 9 to use pointers fixes it: for (auto const * s: { &args... }) $ ./a.out ctor dtor I think that if my code is exploiting some kind of bad behavior (and it likely is), a warning at -Wall would be a nice addition (currently, there is none). If what I'm doing is allowed, I don't think calling a destructor twice is the best idea :) :). I'd be betting money on the first thing, though. Maybe adding something from -fsanitize=undefined would be an option?
[Bug c++/107463] New: Better error request for invalid initializer list of aggregate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107463 Bug ID: 107463 Summary: Better error request for invalid initializer list of aggregate Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- struct S { struct Config { int x; }; S(Config const & cfg); }; void f() { S s({ .y = "x" }); } results in: : In function 'void f()': :11:6: error: no matching function for call to 'S::S()' 11 | }); | ^ :5:5: note: candidate: 'S::S(const Config&)' 5 | S(Config const & cfg); | ^ :5:22: note: no known conversion for argument 1 from '' to 'const S::Config&' 5 | S(Config const & cfg); | ~~~^~~ :1:8: note: candidate: 'constexpr S::S(const S&)' 1 | struct S { |^ :1:8: note: no known conversion for argument 1 from '' to 'const S&' :1:8: note: candidate: 'constexpr S::S(S&&)' :1:8: note: no known conversion for argument 1 from '' to 'S&&' It would be a lot more helpful if the error was something like "there's no member named y in Config, did you mean x?" PR71542 seems related, but different.
[Bug c/103996] New: Enhancement: Better diagnostic for invalid reuse of a function name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103996 Bug ID: 103996 Summary: Enhancement: Better diagnostic for invalid reuse of a function name Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Related email thread: https://gcc.gnu.org/pipermail/gcc-help/2022-January/141117.html I recently hit this problem: #include void f() { index[0] = 0; } #gcc is 11.2.0 gcc -c a.c a.c:4:7: error: subscripted value is neither array nor pointer nor vector 4 | index[1] = 0; | ^ I could not find a compiler option that would tell me what the root cause was. I wasn't getting a simple "undeclared" error, so I surmised the name must already be in use, but I was confused as to how or where it was being used. My first thought was that maybe index was a global variable, so I tried using -Wshadow. Eventually, I found that it was a function from strings.h which was included several layers down an include spiral. I think an effective note from gcc such as "index was previously declared here as a function", or something similar that often happens in other diagnostics, would aid in finding the root cause of my bug. Incidentally, in my actual scenario, the real bug was that I forgot to access index as a member of a struct: x.index vs index. But I'd wager that expecting GCC to look for all nearby structs for a similarly named member is unreasonable. Simply telling me where index originates, though, would have helped greatly.
[Bug other/102060] New: -Wprio-ctor-dtor underlines the wrong part of the source line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102060 Bug ID: 102060 Summary: -Wprio-ctor-dtor underlines the wrong part of the source line Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- We get a warning when building for windows that should be fixed, but it highlights that the warning is slightly mistaken about where the problem is: gcc-git/libgcc/config/i386/cygming-crtend.c:59:1: warning: constructor priorities from 0 to 100 are reserved for the implementation [-Wprio-ctor-dtor] 59 | static void register_frame_ctor (void) __attribute__ ((constructor (0))); | ^~ The word "static" is underlined, but I presume that instead it should be "constructor(0)".
[Bug analyzer/102052] New: analyser testsuite failures with LLP64 model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102052 Bug ID: 102052 Summary: analyser testsuite failures with LLP64 model Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- Additional details here: https://gcc.gnu.org/pipermail/gcc/2021-August/237158.html pr98969.c:9:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] * This fails because the function arguments are "long int", and that tries to hold a pointer. It should be uintptr_t or similar. Something like this should work: diff --git a/gcc/testsuite/gcc.dg/analyzer/pr98969.c b/gcc/testsuite/gcc.dg/analyzer/pr98969.c index 7e1587d..770e6d2 100644 --- a/gcc/testsuite/gcc.dg/analyzer/pr98969.c +++ b/gcc/testsuite/gcc.dg/analyzer/pr98969.c @@ -4,14 +4,14 @@ struct foo }; void -test_1 (long int i) +test_1 (__UINTPTR_TYPE__ i) { struct foo *f = (struct foo *)i; f->expr = __builtin_malloc (1024); } /* { dg-bogus "leak" } */ void -test_2 (long int i) +test_2 (__UINTPTR_TYPR__ i) { __builtin_free (((struct foo *)i)->expr); __builtin_free (((struct foo *)i)->expr); /* { dg-warning "double-'free' of '\\*\\(\\(struct foo \\*\\)i\\)\\.expr'" } */ pr99716-2.c:13:30: warning: implicit declaration of function 'random';did you mean 'rand'? [-Wimplicit-function-declaration] * The C function is rand(), so it's not clear to me at least why the code is using random. I have no idea what the test is testing, so I don't know if rand() is a drop in replacement, but here you go: index 7c9881c..adc9819 100644 --- a/gcc/testsuite/gcc.dg/analyzer/pr99716-2.c +++ b/gcc/testsuite/gcc.dg/analyzer/pr99716-2.c @@ -10,7 +10,7 @@ extern int foo (void); void test_mountpoint (const char *mp) { - const int nr_passes = 5 + (random () & 31); + const int nr_passes = 5 + (rand () & 31); int pass; int ret = 1; FILE *fp; pr99774-1.c:12:14: warning: conflicting types for built-in function 'calloc'; expected 'void *(long long unsigned int, long long unsigned int)' [-Wbuiltin-declaration-mismatch] zlib-5.c:10:15: warning: conflicting types for built-in function 'strlen'; expected 'long long unsigned int(const char *)' [-Wbuiltin-declaration-mismatch] zlib-5.c:16:14: warning: conflicting types for built-in function 'calloc'; expected 'void *(long long unsigned int, long long unsigned int)' [-Wbuiltin-declaration-mismatch] * These are all examples of hardcoding a size_t typedef that is incorrect for an LLP64 model. Something like this would probably be enough to fix it: diff --git a/gcc/testsuite/gcc.dg/analyzer/pr99774-1.c b/gcc/testsuite/gcc.dg/analyzer/pr99774-1.c index 620cf65..a2138d9 100644 --- a/gcc/testsuite/gcc.dg/analyzer/pr99774-1.c +++ b/gcc/testsuite/gcc.dg/analyzer/pr99774-1.c @@ -7,9 +7,8 @@ typedef unsigned char uint8_t; typedef unsigned short uint16_t; typedef unsigned long uint64_t; typedef unsigned long uint64_t; -typedef long unsigned int size_t; -extern void *calloc(size_t __nmemb, size_t __size) +extern void *calloc(__SIZE_TYPE__ __nmemb, __SIZE_TYPE__ __size) __attribute__((__nothrow__, __leaf__)) __attribute__((__malloc__)) __attribute__((__alloc_size__(1, 2))) diff --git a/gcc/testsuite/gcc.dg/analyzer/zlib-5.c b/gcc/testsuite/gcc.dg/analyzer/zlib-5.c index afb6102..93df2b1 100644 --- a/gcc/testsuite/gcc.dg/analyzer/zlib-5.c +++ b/gcc/testsuite/gcc.dg/analyzer/zlib-5.c @@ -2,18 +2,17 @@ #include "analyzer-decls.h" -typedef long unsigned int size_t; typedef unsigned char Byte; typedef unsigned int uInt; typedef unsigned long uLong; -extern size_t strlen(const char *__s) __attribute__((__nothrow__, __leaf__)) +extern __SIZE_TYPE__ strlen(const char *__s) __attribute__((__nothrow__, __leaf__)) __attribute__((__pure__)) __attribute__((__nonnull__(1))); extern void exit(int __status) __attribute__((__nothrow__, __leaf__)) __attribute__((__noreturn__)); extern char *strcpy(char *__restrict __dest, const char *__restrict __src) __attribute__((__nothrow__, __leaf__)) __attribute__((__nonnull__(1, 2))); -extern void *calloc(size_t __nmemb, size_t __size) +extern void *calloc(__SIZE_TYPE__ __nmemb, __SIZE_TYPE__ __size) __attribute__((__nothrow__, __leaf__)) __attribute__((__malloc__)); extern int compress(Byte *dest, uLong *destLen, const Byte *source, strndup-1.c:9:13: warning: incompatible implicit declaration of built-in function 'strndup' [-Wbuiltin-declaration-mismatch] * This function doesn't exist on windows. So, either we add it to libmingwex if it isn't already there and then link that library in to the test, or
[Bug c/102010] New: ICE in stack-check-8.c in i386_pe_seh_unwind_emit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102010 Bug ID: 102010 Summary: ICE in stack-check-8.c in i386_pe_seh_unwind_emit Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- See related PR97795 and PR90458 The testsuite test stack-check-8.c fails thusly: spawn -ignore SIGHUP /tmp/_/build/gc/gcc/xgcc -B/tmp/_/build/gc/gcc/ /tmp/_/src/gcc-git/gcc/testsuite/gcc.dg/stack-check-8.c -fdiagnostics-plain-output -O2 -fstack-clash-protection -Wno-psabi -fno- optimize-sibling-calls --param stack-clash-protection-probe-interval=12 --param stack-clash-protection-guard-size=12 -lm -o ./stack-check-8.exe during RTL pass: final /tmp/_/src/gcc-git/gcc/testsuite/gcc.dg/stack-check-8.c: In function 'f3': /tmp/_/src/gcc-git/gcc/testsuite/gcc.dg/stack-check-8.c:40:1: internal compiler error: in i386_pe_seh_unwind_emit, at config/i386/winnt.c:1274 0x7f25c7 i386_pe_seh_unwind_emit(_IO_FILE*, rtx_insn*) /tmp/_/src/gcc-git/gcc/config/i386/winnt.c:1274 0xb3aa3b final_scan_insn_1 /tmp/_/src/gcc-git/gcc/final.c:2904 0xb3ae5b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) /tmp/_/src/gcc-git/gcc/final.c:2940 0xb3af36 final_1 /tmp/_/src/gcc-git/gcc/final.c:1997 0xb3baf4 rest_of_handle_final /tmp/_/src/gcc-git/gcc/final.c:4285 0xb3baf4 execute /tmp/_/src/gcc-git/gcc/final.c:4363 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. compiler exited with status 1