[Bug target/94770] New: class with empty base passed incorrectly with -std=c++17 on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770 Bug ID: 94770 Summary: class with empty base passed incorrectly with -std=c++17 on mingw Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sbence92 at gmail dot com Target Milestone: --- Created attachment 48376 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48376&action=edit preprocessed failing tests Similar to Bug #94383, Bug #94704 and Bug #94706 the below tests fail with gcc 10 (ead1c27a530) with mingw host and target (also with gcc 9.3 taken from msys2). FAIL: tmpdir-g++.dg-struct-layout-1/t032 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t033 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t034 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t051 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t055 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t056 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t058 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t059 cp_compat_x_tst.o-cp_compat_y_tst.o execute tmpdir-g++-dg-struct-layout-1-t032-01.exe fail 30.71 tmpdir-g++-dg-struct-layout-1-t033-01.exe fail 385.71 tmpdir-g++-dg-struct-layout-1-t034-01.exe fail 798.71 tmpdir-g++-dg-struct-layout-1-t051-01.exe fail 1817.71 tmpdir-g++-dg-struct-layout-1-t055-01.exe fail 2002.71 tmpdir-g++-dg-struct-layout-1-t056-01.exe fail 2200.71 tmpdir-g++-dg-struct-layout-1-t058-01.exe fail 2604.71 tmpdir-g++-dg-struct-layout-1-t059-01.exe fail 2828.71
[Bug c++/94771] New: g++.dg/concepts/diagnostic10.C fails on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94771 Bug ID: 94771 Summary: g++.dg/concepts/diagnostic10.C fails on mingw Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sbence92 at gmail dot com Target Milestone: --- g++.dg/concepts/diagnostic10.C fails with gcc 10 (ead1c27a530) on mingw target and host. Instead of diagnostic10.C:6:31: error: invalid use of non-static member function 'int S::f()' we get diagnostic10.C:6:31: error: statement cannot resolve address of overloaded function. Seems like the fix for Bug 52597 (typeck.c invalid_nonstatic_memfn_p) went with a special case for -fms-extensions which is a default for mingw. Compiling with -fno-ms-extensions provides the correct diagnostic.
[Bug target/94770] class with empty base passed incorrectly with -std=c++17 on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770
--- Comment #2 from Bence Szabó ---
Yes there's a T(30,struct{}a[1];,) in t032.
Indeed the fail happens on a variadic function (void check30va(int i, ...)).
I dig in some more and it turns out all the tests listed crash. I've attached
the formated preprocessed source for t032.
[Bug target/94770] class with empty base passed incorrectly with -std=c++17 on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770 --- Comment #3 from Bence Szabó --- Created attachment 48379 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48379&action=edit t032
[Bug target/94770] class with empty base passed incorrectly with -std=c++17 on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770 --- Comment #4 from Bence Szabó --- As a remark for 'same code with -std=c++14 and -std=c++17 here', I can confirm, the example you provided also produces same assembly for me in c++14 and c++17. Also compiling t032 with only c++14 or only c++17 still results in a failing test case (30.71) and then a crash. Maybe this is not the same abi problem?
[Bug target/94770] class with empty base passed incorrectly with -std=c++17 on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770 --- Comment #6 from Bence Szabó --- > Ah, then it is not c++14 vs. c++17 ABI incompatibility, but some bug in > va_arg passing of such classes for mingw. It seems so. In t032 I got rid of the crashing tests (30, 56, 77, 80, 89, 100, 117, 134, 162, 171, 174, 191, 250 all of them are the second variadic test case) and the rest of the tests pass in t032. Same in t059: 2998, 2828 crash on 2nd variadic test the rest passes. Sorry for misleading bug report, I saw the same test cases fail as the mentioned reports, didn't know the reason is so different.
[Bug c++/94771] g++.dg/concepts/diagnostic10.C fails on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94771 --- Comment #4 from Bence Szabó --- Interesting, the t.f syntax is not allowed anymore even with MSVC: https://godbolt.org/z/YCK-mv msvc also doesn't list under extensions_ https://docs.microsoft.com/en-us/cpp/build/reference/microsoft-extensions-to-c-and-cpp?view=vs-2015 and some recent overview on ms extensions: https://stackoverflow.com/questions/56554567/what-does-the-ms-extensions-flag-do-exactly-with-gcc Is this a dinosaur that forgot to die?
[Bug target/94770] class with empty base passed incorrectly with -std=c++17 on mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94770 --- Comment #14 from Bence Szabó --- (In reply to Jakub Jelinek from comment #13) > Completely untested WIP patch: Results with ead1c27a530 + this patch: The same tests fail as in the original description, t032 and t059 crash/pass the same way as described in comment 6. Also, running the testsuite (check-c++) shows new failed tests: FAIL: g++.dg/compat/abi/pr83487-1 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: g++.dg/compat/abi/pr83487-2 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: g++.dg/lookup/ns1.C -std=c++98 (test for excess errors) FAIL: g++.dg/torture/pr39417.C -O0 execution test FAIL: g++.old-deja/g++.robertl/eb21.C -std=c++14 execution test (timeout) FAIL: g++.old-deja/g++.robertl/eb21.C -std=c++17 execution test (timeout) FAIL: g++.old-deja/g++.robertl/eb21.C -std=c++2a execution test (timeout)
[Bug c++/92359] New: function static variable instantiated at -O1 despite extern template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92359
Bug ID: 92359
Summary: function static variable instantiated at -O1 despite
extern template
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
Target Milestone: ---
Host: all
Target: all
Build: all
Created attachment 47169
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47169&action=edit
minimal example
In the below example func is inlined and function_local_static becomes a
defined symbol when compiled with -O1 and above regardless of extern template
class declaration.
The problem is solved by adding -fno-inline to -O1 or -Og, but not with -O2 and
above.
Same can be observed with all gcc versions, clang 5.0+ (works with 4.0.1), icc,
but not with msvc.
This is problematic when one tries to rely on the extern template mechanism in
shared libraries. The result is that function static variables get instantiated
more than 1 times.
Attached you find a minimal example showing exactly this.
template
struct S {
int func() {
static int function_local_static = 0;
return ++function_local_static;
}
};
extern template class S;
int user()
{
return S().func();
}
[Bug c++/92359] function static variable instantiated at -O1 despite extern template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92359 --- Comment #2 from Bence Szabó --- Is it a subtle thing that all implementations missed or is it not specified very well in the standard? As far as I could tell there's no specific rule for this case. The standard is detailed about member statics, member functions etc but not about this. Thoughts?
[Bug c++/92517] New: ICE on incorrect syntax involving requires and decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92517
Bug ID: 92517
Summary: ICE on incorrect syntax involving requires and
decltype
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
Target Milestone: ---
Naively adding decltype with wrong syntax in order fix "expected a type, got
'I'" results in segfault with following code:
template
concept C = true;
template
requires C decltype
void f() {}
flags: -std=c++2a -fconcepts
gcc 9.2 produces correct error message
[Bug c++/92517] [10 Regression] ICE on incorrect syntax involving requires and decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92517 --- Comment #1 from Bence Szabó --- started with r276764
[Bug bootstrap/88450] New: ICE in stage 2 compiler while configuring libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
Bug ID: 88450
Summary: ICE in stage 2 compiler while configuring libgcc
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
Target Milestone: ---
Created attachment 45206
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45206&action=edit
main config.log
Bootstrap fails under Win10 at configuring libgcc in stage2 with
x86_64-w64-mingw32 host/target. Bootstraps succeeds with 9-20181118 snapshot
with same configuration/toolchain and fails at the same point with later
snapshots.
Host: win10, mingw64 with gcc 8.1 + msys2
configure:3745: checking for suffix of object files
configure:3767: /c/data/gcc9_b/./gcc/xgcc -B/c/data/gcc9_b/./gcc/
-L/usr/x86_64-w64-mingw32/lib -L/usr/mingw/lib -isystem
/usr/x86_64-w64-mingw32/include -isystem /usr/mingw/include
-B/usr/x86_64-w64-mingw32/bin/ -B/usr/x86_64-w64-mingw32/lib/ -isystem
/usr/x86_64-w64-mingw32/include -isystem /usr/x86_64-w64-mingw32/sys-include
-fno-checking -c -g -O2 -pipe -fno-ident conftest.c >&5
conftest.c: In function 'main':
conftest.c:15:3: internal compiler error: Segmentation fault
15 | return 0;
| ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://sourceforge.net/projects/mingw-w64> for instructions.
configure:3771: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3785: error: in `/c/data/gcc9_b/x86_64-w64-mingw32/libgcc':
configure:3787: error: cannot compute suffix of object files: cannot compile
[Bug bootstrap/88450] ICE in stage 2 compiler while configuring libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450 --- Comment #1 from Bence Szabó --- Correction: 9-21081118 works after patching with "PR bootstrap/88106" (r266309)
[Bug bootstrap/88450] ICE in stage 2 compiler while configuring libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450 --- Comment #2 from Bence Szabó --- Bisected, problem starts at r266345 ([PATCH][PR84877]Dynamically align the address for local parameter copy on the stack when required alignment is larger than MAX_SUPPORTED_STACK_ALIGNMEN).
[Bug bootstrap/88450] [9 regression] ICE in stage 2 compiler while configuring libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450 --- Comment #7 from Bence Szabó --- New info: when built with --enable-checking=yes, the selftests already produce segfault in stage2 cc1 and cc1plus at the same point as the below cc1plus. backtrace for cc1 with r266345. Thread 1 received signal SIGSEGV, Segmentation fault. 0x0045953d in c_parser_declspecs (parser=parser@entry=0x1965b708, specs=specs@entry=0x1967d750, scspec_ok=scspec_ok@entry=true, typespec_ok=typespec_ok@entry=true, start_attr_ok=, start_attr_ok@entry=true, alignspec_ok=, alignspec_ok@entry=true, auto_type_ok=, auto_type_ok@entry=true, la=, la@entry=cla_nonabstract_decl) at ../../src/gcc/c/c-parser.c:2776 2776 declspecs_add_type (loc, specs, t); (gdb) bt #0 0x0045953d in c_parser_declspecs (parser=parser@entry=0x1965b708, specs=specs@entry=0x1967d750, scspec_ok=scspec_ok@entry=true, typespec_ok=typespec_ok@entry=true, start_attr_ok=, start_attr_ok@entry=true, alignspec_ok=, alignspec_ok@entry=true, auto_type_ok=, auto_type_ok@entry=true, la=, la@entry=cla_nonabstract_decl) at ../../src/gcc/c/c-parser.c:2776 #1 0x00471579 in c_parser_declaration_or_fndef (parser=0x1965b708, fndef_ok=true, static_assert_ok=, empty_ok=true, nested=false, start_attr_ok=true, objc_foreach_object_declaration=0x0, omp_declare_simd_clauses=..., oacc_routine_data=0x0, fallthru_attr_p=0x0) at ../../src/gcc/c/c-parser.c:1850 #2 0x00479f33 in c_parser_external_declaration (parser=0x1965b708) at ../../src/gcc/c/c-parser.c:1653 #3 0x0047a95c in c_parser_translation_unit (parser=) at ../../src/gcc/c/c-parser.c:1534 #4 c_parse_file () at ../../src/gcc/c/c-parser.c:19771 #5 0x004d1af7 in c_common_parse_file () at ../../src/gcc/c-family/c-opts.c:1151 #6 0x00925a4d in compile_file () at ../../src/gcc/toplev.c:456 #7 0x01587bff in do_compile () at ../../src/gcc/toplev.c:2176 #8 toplev::main(int, char**) () at ../../src/gcc/toplev.c:2311 #9 0x016d67f3 in main (argc=2, argv=0x197115d0) at ../../src/gcc/main.c:39 === backtrace for cc1plus with r266345: Thread 1 received signal SIGSEGV, Segmentation fault. 0x00855ac6 in gimplify_expr (expr_p=, pre_p=, pre_p@entry=0x1ab1f948, post_p=, post_p@entry=0x0, gimple_test_f=, gimple_test_f@entry=0x8478f0 , fallback=, fallback@entry=0) at ../../src/gcc/gimplify.c:13249 13249 annotate_all_with_location_after (*pre_p, pre_last_gsi, input_location); (gdb) bt #0 0x00855ac6 in gimplify_expr (expr_p=, pre_p=, pre_p@entry=0x1ab1f948, post_p=, post_p@entry=0x0, gimple_test_f=, gimple_test_f@entry=0x8478f0 , fallback=, fallback@entry=0) at ../../src/gcc/gimplify.c:13249 #1 0x0085f0bf in gimplify_stmt (stmt_p=stmt_p@entry=0x1ab1f3f8, seq_p=seq_p@entry=0x1ab1f948) at ../../src/gcc/gimplify.c:6656 #2 0x0086a17a in gimplify_and_add (seq_p=0x1ab1f948, t=) at ../../src/gcc/gimplify.c:465 #3 gimplify_return_expr (stmt=stmt@entry=0x1decc5a0, pre_p=pre_p@entry=0x1ab1f948) at ../../src/gcc/gimplify.c:1591 #4 0x00857c1e in gimplify_expr (expr_p=, pre_p=pre_p@entry=0x1ab1f948, post_p=, post_p@entry=0x0, gimple_test_f=, gimple_test_f@entry=0x8478f0 , fallback=, fallback@entry=0) at ../../src/gcc/gimplify.c:12634 #5 0x0085f0bf in gimplify_stmt (stmt_p=, seq_p=seq_p@entry=0x1ab1f948) at ../../src/gcc/gimplify.c:6656 #6 0x00857fb3 in gimplify_statement_list (pre_p=0x1ab1f948, expr_p=) at ../../src/gcc/tree-iterator.h:86 #7 gimplify_expr (expr_p=, pre_p=pre_p@entry=0x1ab1f948, post_p=, post_p@entry=0x0, gimple_test_f=, gimple_test_f@entry=0x8478f0 , fallback=, fallback@entry=0) at ../../src/gcc/gimplify.c:12802 #8 0x0085f0bf in gimplify_stmt (stmt_p=stmt_p@entry=0x1ded4ec0, seq_p=seq_p@entry=0x1ab1f948) at ../../src/gcc/gimplify.c:6656 #9 0x00860ada in gimplify_body (fndecl=fndecl@entry=0x1ded4e00, do_parms=do_parms@entry=true) at ../../src/gcc/tree.h:3155 #10 0x00860eaa in gimplify_function_tree (fndecl=fndecl@entry=0x1ded4e00) at ../../src/gcc/gimplify.c:13726 #11 0x006e34f3 in cgraph_node::analyze (this=this@entry=0x1d0a82e0) at ../../src/gcc/cgraphunit.c:667 #12 0x006e5f5e in analyze_functions (first_time=first_time@entry=true) at ../../src/gcc/cgraphunit.c:1126 #13 0x006e6ce5 in symbol_table::finalize_compilation_unit (this=0x1d0a9100) at ../../src/gcc/cgraphunit.c:2835 #14 0x00a90739 in compile_file () at ../../src/gcc/toplev.c:481 #15 0x017b39df in do_compile () at ../../src/gcc/toplev.c:2176 #16 toplev::main(int, char**) () at ../../src/gcc/toplev.c:2311 #17 0x01902d73 in main (argc=2, argv=0x1a15d0) at ../../src/gcc/main.c:39
[Bug bootstrap/88450] [9 regression] ICE in stage 2 compiler while configuring libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450 --- Comment #10 from Bence Szabó --- cc1: segfault at vmovaps 2776 declspecs_add_type (loc, specs, t); 0045952e: ...kahead_kind)+1070 mov %rbp,%r8 00459531: ...kahead_kind)+1073 vmovdqa 0xa0(%rsp),%xmm1 0045953a: ...kahead_kind)+1082 mov %r13,%rdx 0045953d: ...kahead_kind)+1085 vmovaps %xmm1,0x0(%rbp) 00459542: ...kahead_kind)+1090 mov 0xb0(%rsp),%rax 0045954a: ...kahead_kind)+1098 mov %ebx,%ecx 0045954c: ...kahead_kind)+1100 mov %rax,0x10(%rbp) 00459550: ...kahead_kind)+1104 mov %r15d,%esi 00459553: ...kahead_kind)+1107 mov %r15d,%edi 00459556: ...kahead_kind)+1110 callq 0x412a80 cc1plus: segfault at vmovaps 13249 annotate_all_with_location_after (*pre_p, pre_last_gsi, input_location); 00855ab5: ...node*), int)+2085 mov 0xb8(%rsp),%rdx 00855abd: ...node*), int)+2093 vmovdqa 0x130(%rsp),%xmm1 00855ac6: ...node*), int)+2102 vmovaps %xmm1,(%rdx) 00855aca: ...node*), int)+2106 mov 0x140(%rsp),%rax 00855ad2: ...node*), int)+2114 mov %rax,0x10(%rdx) 00855ad6: ...node*), int)+2118 mov 0x18286c3(%rip),%rax# 0x207e1a0 <.refptr.input_location> 00855add: ...node*), int)+2125 mov (%rax),%r8d 00855ae0: ...node*), int)+2128 callq 0x816a50
[Bug bootstrap/88450] [9 regression] ICE in stage 2 compiler while configuring libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450 --- Comment #11 from Bence Szabó --- Created attachment 45279 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45279&action=edit preprocessed c-parser, gimplify
[Bug bootstrap/88450] [9 regression] ICE in stage 2 compiler while configuring libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450 --- Comment #13 from Bence Szabó --- ICE still occurs with current trunk (r267728) patched with gcc9-pr88331.patch from PR88331. r266345 seems to give quite a hard time for cygwin / mingw targets, might be worth reverting as the gcc 9 release is comming up.
[Bug bootstrap/88450] [9 regression] ICE in stage 2 compiler while configuring libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450 --- Comment #21 from Bence Szabó --- Bootstrap succeeds with trunk + gcc9-pr88450.patch. Ran gcc testsuite, all stackalignment tests pass and so does the test added by r266345. The CPU was an Intel Coffee Lake so avx and avx2 is supported but avx512 is not.
[Bug c++/88951] New: No fpermissive offerred on 'error: jump to case label'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88951
Bug ID: 88951
Summary: No fpermissive offerred on 'error: jump to case label'
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
Target Milestone: ---
r263551 removes the possibility to compile the below code with fpermissive.
This code has always been compiled by GCC, why remove the option now? This
breaks backward compatibility with some legacy code.
void f()
{
switch(0)
{
int x = 0;
case 0:
}
}
[Bug c++/88951] [9 Regression] No fpermissive offerred on 'error: jump to case label'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88951 --- Comment #4 from Bence Szabó --- Ok, I agree with all of what you wrote. Please close the PR as you wish.
[Bug sanitizer/90312] New: Address sanitizer cannot be used with -mabi=ms since r266073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90312 Bug ID: 90312 Summary: Address sanitizer cannot be used with -mabi=ms since r266073 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: sbence92 at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org, mliska at suse dot cz Target Milestone: --- Target: x86_64-w64-mingw32 Build: x86_64-w64-mingw32 The fix or PR sanitizer/87930 (r266073) makes it impossible to use -fsanitize=address on windows which uses -mabi=ms as default. Currently the mingw releases do not contain libasan (or libusan) and so far my attempts to include them failed. However there's a mingw based llvm toolchain (https://github.com/mstorsjo/llvm-mingw) which contains libasan and libusan as static lib. These can be linked to a dll by the said toolchain and they work with mingw as drop-in until gcc 8.3. I guess PR sanitizer/87930 could be fixed instead of forbidden. It would be awesome to use the asan (and usan) with mingw but that's currently impossible after r266073 even if we produce the libasan for mingw somehow.
[Bug sanitizer/90312] Address sanitizer cannot be used with -mabi=ms since r266073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90312
--- Comment #3 from Bence Szabó ---
Thank you for the patch!
The main blocker is some msvc specific code in sanitizer_win_defs.h.
WIN_FORCE_LINK, WIN_WEAK_ALIAS, WIN_EXPORT
AFAIK the sanitizer is from LLVM (or google?) and the official llvm build for
windows is using msvc. So probably no-one has ever tried to compile this for
windows with gcc.
The build dies early in libsanitizer with:
libtool: compile: /c/GIT/gcc/trunk_build/./gcc/xgcc -shared-libgcc
-B/c/GIT/gcc/trunk_build/./gcc -nostdinc++
-L/c/GIT/gcc/trunk_build/x86_64-w64-mingw32/libstdc++-v3/src
-L/c/GIT/gcc/trunk_build/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/c/GIT/gcc/trunk_build/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/c/mingw_83_build/x86_64-w64-mingw32/lib -L/c/mingw_83_build/mingw/lib
-isystem /c/mingw_83_build/x86_64-w64-mingw32/include -isystem
/c/mingw_83_build/mingw/include -B/c/mingw_83_build/x86_64-w64-mingw32/bin/
-B/c/mingw_83_build/x86_64-w64-mingw32/lib/ -isystem
/c/mingw_83_build/x86_64-w64-mingw32/include -isystem
/c/mingw_83_build/x86_64-w64-mingw32/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I../../../../trunk_src/libsanitizer/sanitizer_common -I.. -I
../../../../trunk_src/libsanitizer/include -isystem
../../../../trunk_src/libsanitizer/include/system -Wall -W
-Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables
-fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-w64-mingw32
-I../../../../trunk_src/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -g
-O2 -pipe -fno-ident
-I/c/GIT/gcc/prerequisites/x86_64-w64-mingw32-static/include -MT
sanitizer_common.lo -MD -MP -MF .deps/sanitizer_common.Tpo -c
../../../../trunk_src/libsanitizer/sanitizer_common/sanitizer_common.cc
-DDLL_EXPORT -DPIC -o .libs/sanitizer_common.o
In file included from
c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_internal_defs.h:58,
from
c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_flags.h:15,
from
c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_common.h:17,
from
../../../../trunk_src/libsanitizer/sanitizer_common/sanitizer_common.cc:12:
c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_win_defs.h:66:11:
error: expected constructor, destructor, or type conversion before '(' token
66 | __pragma(comment(linker, "/alternatename:" WIN_SYM_PREFIX
STRINGIFY(Name) "="\
| ^
c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_win_defs.h:94:3:
note: in expansion of macro 'WIN_WEAK_ALIAS'
94 | WIN_WEAK_ALIAS(Name, WEAK_DEFAULT_NAME(Name))
\
| ^~
c:\git\gcc\trunk_src\libsanitizer\sanitizer_common\sanitizer_internal_defs.h:60:3:
note: in expansion of macro 'WIN_WEAK_EXPORT_DEF'
60 | WIN_WEAK_EXPORT_DEF(ReturnType, Name, __VA_ARGS__)
| ^~~
../../../../trunk_src/libsanitizer/sanitizer_common/sanitizer_common.cc:328:1:
note: in expansion of macro 'SANITIZER_INTERFACE_WEAK_DEF'
328 | SANITIZER_INTERFACE_WEAK_DEF(void, __sanitizer_report_error_summary,
| ^~~~
make[4]: *** [Makefile:663: sanitizer_common.lo] Error 1
Same goes for WIN_FORCE_LINK
[Bug c++/61592] ICE with large array with initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61592
Bence Szabó changed:
What|Removed |Added
CC||sbence92 at gmail dot com
--- Comment #2 from Bence Szabó ---
A variant of the is still an issue even with GCC 11.
The below is a reduced version of a file that took 33 minutes(!) to compile,
cc1 starting from 1GB of memory usage, reaching 2GB eventually.
This example generates 10MB of assembly as it unrolls the constructor calls
even with O0.
struct B
{
B() {}
};
struct A
{
B b[128][1875];
};
A a{};
I've tried to find a similar PR, this was the closest one.
Is this a known issue?
[Bug c++/100800] New: ternary operator doesn't accept T with conversion operator and nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100800
Bug ID: 100800
Summary: ternary operator doesn't accept T with conversion
operator and nullptr
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
Target Milestone: ---
Host: x86_64-w64-mingw32, x86_64-linux-gnu
Target: x86_64-w64-mingw32, x86_64-linux-gnu
Build: x86_64-w64-mingw32, x86_64-linux-gnu
The following code fails to compile with the following message:
error: operands to '?:' have different types 'S2' and 'std::nullptr_t'
Even though S2 is convertible to S* and nullptr is convertible to S* so they
have a common type to convert to. Also the standard mentions that pointer
conversion rules are applied to bring the second and third operand to a common
type, so this code seems to be valid.
FYI clang and icc accepts this, msvc and gcc doesn't.
struct S{};
struct S2 {
operator S*();
};
S* f() { return true ? S2{} : nullptr; }
[Bug c++/100807] New: initialization of global struct with large array leads to huge assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100807
Bug ID: 100807
Summary: initialization of global struct with large array leads
to huge assembly
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
Target Milestone: ---
Host: x86_64-w64-mingw32, x86_64-linux-gnu
Target: x86_64-w64-mingw32, x86_64-linux-gnu
Build: x86_64-w64-mingw32, x86_64-linux-gnu
The below is a reduced version of a file that took 33 minutes(!) to compile,
cc1 starting from 1GB of memory usage, reaching 2GB eventually.
This example takes ~12 seconds, ~700 MB of memory and generates 14MB of
assembly as gcc unrolls the constructor calls even with O0 and crashes with O1
and above.
clang and icc is fine, they do this with a loop, msvc kindof the same.
This seems to be and old issue, even gcc 4 timeouts on godbolt.
struct B
{
B() {}
};
struct A
{
B b[128][1875];
};
A a{};
[Bug c++/92359] function static variable instantiated at -O1 despite extern template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92359 --- Comment #4 from Bence Szabó --- >That should not matter in even in shared libraries unless you are doing some >symbol hidding in the shared library really. Hmm. I just run the attached example on linux (after some tuning) with -fPIC, and it works. Strange. Now I don't see why this shouldn't work under windows.
