[Bug tree-optimization/86732] Potential nullptr dereference does not propagate knowledge about the pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86732 --- Comment #8 from Jeffrey A. Law --- I wouldn't object to that. In fact I thought we kicked that around along with an option to remove path leading to the undefined behavior completely. But it's not something I'm likely to work on.
[Bug target/84332] ICE in insn_default_length, at config/s390/s390.md:9697 for -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84332 --- Comment #2 from Martin Liška --- Any progress here please?
[Bug target/86838] New: ICE in gen_aarch64_frecpe, at ./insn-opinit.h:571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86838 Bug ID: 86838 Summary: ICE in gen_aarch64_frecpe, at ./insn-opinit.h:571 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Host: x86_64-linux-gnu Target: aarch64-linux-gnu Following causes ICE: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/recip-7.c -Ofast -mlow-precision-div -c during RTL pass: expand /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/recip-7.c: In function ‘f’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/recip-7.c:10:6: internal compiler error: in gen_aarch64_frecpe, at ./insn-opinit.h:571 void f(int x, double z, double w) ^ 0x1519c40 gen_aarch64_frecpe(machine_mode, rtx_def*, rtx_def*) ./insn-opinit.h:571 0x15046ec aarch64_emit_approx_div(rtx_def*, rtx_def*, rtx_def*) /home/marxin/Programming/gcc/gcc/config/aarch64/aarch64.c:9888 0x1863430 gen_divdf3(rtx_def*, rtx_def*, rtx_def*) /home/marxin/Programming/gcc/gcc/config/aarch64/aarch64.md:5806 0xe49b47 insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*) const /home/marxin/Programming/gcc/gcc/recog.h:302 0xef8535 maybe_gen_insn(insn_code, unsigned int, expand_operand*) /home/marxin/Programming/gcc/gcc/optabs.c:7318 0xee3c27 expand_binop_directly /home/marxin/Programming/gcc/gcc/optabs.c:1098 0xee4120 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) /home/marxin/Programming/gcc/gcc/optabs.c:1185 0xbbd4be expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) /home/marxin/Programming/gcc/gcc/expr.c:9631 0xa28c2d expand_gimple_stmt_1 /home/marxin/Programming/gcc/gcc/cfgexpand.c:3673 0xa28eaa expand_gimple_stmt /home/marxin/Programming/gcc/gcc/cfgexpand.c:3734 0xa31df0 expand_gimple_basic_block /home/marxin/Programming/gcc/gcc/cfgexpand.c:5769 0xa337ee execute /home/marxin/Programming/gcc/gcc/cfgexpand.c:6372
[Bug target/86838] ICE in gen_aarch64_frecpe, at ./insn-opinit.h:571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86838 Martin Liška changed: What|Removed |Added Last reconfirmed||2018-8-3 CC||jgreenhalgh at gcc dot gnu.org, ||kyrylo.tkachov at arm dot com, ||ramana at gcc dot gnu.org Target Milestone|--- |9.0
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #13 from Paul Thomas --- [...] > Does the attachment fix the problem? Seems I completely missed this, sorry. I've just ran sparc-sun-solaris2.11 and i386-pc-solaris2.11 bootstraps last night; unfortunately there was no change with your patch. Rainer
[Bug tree-optimization/86839] New: O3 create wrong code (segmentation fault) on extern non-aligned buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86839 Bug ID: 86839 Summary: O3 create wrong code (segmentation fault) on extern non-aligned buffer Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: galileaman.bugzilla at gmail dot com Target Milestone: --- gcc-5.4 miscompiles the following code on x86_64-linux-gnu at -O3 in 64-bit mode. The resulting binary cause segmentation fault. $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.10' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10) $ g++ -Wall -c simple_struct.cpp $ g++ -Wall -O2 simple.cpp simple_struct.o $ ./a.out After alignInt, address 0x7fffc21fb274 After nonAlignInt, address 0x7fffc21fb211 After alignExt, address 0x6011a4 After nonAlignExt, address 0x601201 $ g++ -Wall -O3 simple.cpp simple_struct.o $ ./a.out After alignInt, address 0x7ffce7dd6fa4 After nonAlignInt, address 0x7ffce7dd6f41 After alignExt, address 0x6021a4 Segmentation fault (core dumped) simple_struct.h: #ifndef _TEST_H #define _TEST_H #pragma pack(push) #pragma pack(1) #define BUF_LEN (20) struct BufNonAligned { char buf[1]; float vals[BUF_LEN]; }; #pragma pack(pop) #pragma pack(push) #pragma pack(1) struct BufAligned { char buf[4]; float vals[BUF_LEN]; }; #pragma pack(pop) #endif simple_struct.cpp: #include "simple_struct.h" struct BufAlignedalignExt; struct BufNonAligned nonAlignExt; --- simple.cpp: #include #include "simple_struct.h" extern BufAlignedalignExt; extern BufNonAligned nonAlignExt; int main(void) { struct BufAlignedalignInt; struct BufNonAligned nonAlignInt; float val = 0.5; for (float *p = alignInt.vals; p != alignInt.vals + BUF_LEN ; p++) { *p = val; } std::cout << "\tAfter alignInt, address " << alignInt.vals << std::endl; for (float *p = nonAlignInt.vals; p != nonAlignInt.vals + BUF_LEN ; p++) { *p = val; } std::cout << "\tAfter nonAlignInt, address " << nonAlignInt.vals <
[Bug tree-optimization/80925] [8 Regression] vect peeling failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #30 from Rainer Orth --- (In reply to Steve Ellcey from comment #22) Finally coming back to this... > Ranier Orth reported a failure on SPARC64 as well, here was my reply > to him. I don't know if your problem is the same without seeing the > specific failure. > > -- > > Looking at the checks at the end, I also see that SPARC does include > the 'Alignment' message and Aarch64 does not and that is handled by a > conditional check. > > I think the fix is to check for 'vectorized 4 loops' when we support > unaligned vector instructions (vect_hw_misalign is true) and check for > 'vectorized 3 loops' otherwise. Does that sound reasonable to you? I just successfully tested a patch along these lines on sparc-sun-solaris2.11 and i386-pc-solaris2.11: works fine. I'll also test on the gcc-8 branch which is likewise affected and then post to gcc-patches. Thanks for the suggestion. Rainer
[Bug tree-optimization/80925] [8 Regression] vect peeling failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925 --- Comment #31 from Rainer Orth --- Created attachment 44498 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44498&action=edit Proposed patch for gcc.dg/vect/no-section-anchors-vect-69.c failure
[Bug tree-optimization/86839] O3 create wrong code (segmentation fault) on extern non-aligned buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86839 --- Comment #1 from Andrew Pinski --- Try using -fsanitizer=undefined . As I think you are violating c/c++ alignment rules. That is a pointer to a float has an alignment requirement of 4 bytes but your pointer that you are using only has an alignment of 1 byte.
[Bug target/86838] [9 Regression] ICE in gen_aarch64_frecpe, at ./insn-opinit.h:571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86838 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||ktkachov at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Summary|ICE in gen_aarch64_frecpe, |[9 Regression] ICE in |at ./insn-opinit.h:571 |gen_aarch64_frecpe, at ||./insn-opinit.h:571 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed, appeared very recently. I suspect it's fallout from r263251 ?
[Bug tree-optimization/86839] O3 create wrong code (segmentation fault) on extern non-aligned buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86839 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Jakub Jelinek --- Yeah, clearly invalid.
[Bug c++/86836] internal compiler error on structured bindings with shadow parameter on templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86836 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Without templates: struct A { int operator*(); void operator++(); bool operator!=(A); }; class map { public: A begin(); A end(); }; void mergemap(map orig, map toadd) { for (auto p : toadd) auto [orig] = orig; } int main() { map x, y; mergemap(x, y); } this is rejected with: pr86836-2.C: In function ‘void mergemap(map, map)’: pr86836-2.C:14:19: error: use of ‘orig’ before deduction of ‘auto’ auto [orig] = orig; ^~~~
[Bug middle-end/86840] New: __attribute__((optimize("exceptions"))) is silently ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86840 Bug ID: 86840 Summary: __attribute__((optimize("exceptions"))) is silently ignored Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Consider test.c: ... void a (void); void do_cleanup (void *p); void #ifdef E __attribute__((optimize("exceptions"))) #endif b (void) { int c __attribute__((cleanup(do_cleanup))); a(); } ... When enabling exceptions, an exception table is generated: ... $ gcc test.c -o- -S -O2 -fexceptions | grep -c "\.gcc_except_table" 2 ... And when disabling exceptions, it's not: ... $ gcc test.c -o- -S -O2 -fno-exceptions | grep -c "\.gcc_except_table" 0 ... When enabling exceptions using the attribute on function b, no exception table is generated: ... $ gcc test.c -o- -S -O2 -fno-exceptions -DE | grep -c "\.gcc_except_table" 0 ... This should have a warning "attribute ignored", and/or document this more clearly in the documentation of fexceptions and/or the optimize attribute.
[Bug c++/86836] internal compiler error on structured bindings with shadow parameter on templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86836 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- I've tried to defer the assert until after cp_finish_decl: --- pt.c.jj12018-07-31 23:57:23.0 +0200 +++ pt.c2018-08-03 11:11:41.384454435 +0200 @@ -16555,10 +16555,7 @@ tsubst_decomp_names (tree decl, tree pat decl2 = DECL_CHAIN (decl2)) { if (TREE_TYPE (decl2) == error_mark_node && *cnt == 0) - { - gcc_assert (errorcount); - return error_mark_node; - } + return error_mark_node; (*cnt)++; gcc_assert (DECL_DECOMP_BASE (decl2) == pattern_decl); gcc_assert (DECL_HAS_VALUE_EXPR_P (decl2)); @@ -16572,7 +16569,6 @@ tsubst_decomp_names (tree decl, tree pat DECL_TEMPLATE_INSTANTIATED (decl3) = 1; else { - gcc_assert (errorcount); decl = error_mark_node; continue; } @@ -16582,10 +16578,7 @@ tsubst_decomp_names (tree decl, tree pat else if (decl != error_mark_node && DECL_CHAIN (decl3) != prev && decl != prev) - { - gcc_assert (errorcount); - decl = error_mark_node; - } + decl = error_mark_node; else prev = decl3; } @@ -16770,6 +16763,8 @@ tsubst_expr (tree t, tree args, tsubst_f cp_finish_decl (decl, init, const_init, NULL_TREE, 0); if (ndecl != error_mark_node) cp_finish_decomp (ndecl, first, cnt); + else + gcc_assert (errorcount); } else cp_finish_decl (decl, init, const_init, NULL_TREE, 0); @@ -16813,9 +16808,13 @@ tsubst_expr (tree t, tree args, tsubst_f tree decomp_first = NULL_TREE; unsigned decomp_cnt = 0; if (VAR_P (decl) && DECL_DECOMPOSITION_P (decl)) - decl = tsubst_decomp_names (decl, RANGE_FOR_DECL (t), args, - complain, in_decl, - &decomp_first, &decomp_cnt); + { + decl = tsubst_decomp_names (decl, RANGE_FOR_DECL (t), args, + complain, in_decl, + &decomp_first, &decomp_cnt); + if (decl == error_mark_node) + gcc_assert (errorcount); + } if (processing_template_decl) { but that doesn't help, the bug isn't diagnosed in this case either. For some reason, the orig decomp VAR_DECL is tsubsted to the PARM_DECL rather than a new VAR_DECL representing the structured binding id, and thus also cp_finish_decl succeeds. Giving up here.
[Bug tree-optimization/86839] O3 create wrong code (segmentation fault) on extern non-aligned buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86839 --- Comment #3 from galileaman bugzilla --- OK, always thought that non-aligned vars only hit performance. I see know it is a requirement in the standard. Sorry, and thanks.
[Bug tree-optimization/86841] New: ICE in /home/marxin/Programming/gcc/gcc/tree-vrp.c:1325 with graphite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86841 Bug ID: 86841 Summary: ICE in /home/marxin/Programming/gcc/gcc/tree-vrp.c:1325 with graphite Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: msebor at gcc dot gnu.org, rguenth at gcc dot gnu.org Blocks: 59859 Target Milestone: --- Following causes ICE: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/allocate_with_source_24.f90 -Ofast -floop-parallelize-all -c -fdump-tree-all-gimple during GIMPLE pass: printf-return-value dump file: allocate_with_source_24.f90.170t.printf-return-value2 /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/allocate_with_source_24.f90:93:0: end module iso_varying_string internal compiler error: in zext_hwi, at hwint.h:314 0xfb5147 zext_hwi /home/marxin/Programming/gcc/gcc/hwint.h:314 0xfb5147 unsigned long wi::extract_uhwi >(generic_wide_int const&, unsigned int, unsigned int) /home/marxin/Programming/gcc/gcc/wide-int.h:3205 0xfb5147 wide_int_range_lshift(generic_wide_int&, generic_wide_int&, signop, unsigned int, generic_wide_int const&, generic_wide_int const&, generic_wide_int const&, generic_wide_int const&, bool, bool) /home/marxin/Programming/gcc/gcc/tree-vrp.c:1325 0xfc071c extract_range_from_binary_expr_1(value_range*, tree_code, tree_node*, value_range*, value_range*) /home/marxin/Programming/gcc/gcc/tree-vrp.c:2271 0x1027506 vr_values::extract_range_from_binary_expr(value_range*, tree_code, tree_node*, tree_node*, tree_node*) /home/marxin/Programming/gcc/gcc/vr-values.c:768 0x1029830 vr_values::extract_range_from_assignment(value_range*, gassign*) /home/marxin/Programming/gcc/gcc/vr-values.c:1429 0x1504e6b evrp_range_analyzer::record_ranges_from_stmt(gimple*, bool) /home/marxin/Programming/gcc/gcc/gimple-ssa-evrp-analyze.c:293 0x15292b0 before_dom_children /home/marxin/Programming/gcc/gcc/gimple-ssa-sprintf.c:4063 0x14e4e07 dom_walker::walk(basic_block_def*) /home/marxin/Programming/gcc/gcc/domwalk.c:353 0x1529375 execute /home/marxin/Programming/gcc/gcc/gimple-ssa-sprintf.c:4091 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 [Bug 59859] [meta-bug] GRAPHITE issues
[Bug tree-optimization/86841] ICE in /home/marxin/Programming/gcc/gcc/tree-vrp.c:1325 with graphite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86841 Martin Liška changed: What|Removed |Added Target Milestone|--- |9.0 Known to fail||9.0
[Bug c++/86836] internal compiler error on structured bindings with shadow parameter on templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86836 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 44499 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44499&action=edit gcc9-pr86836.patch Actually, this seems to work, just tsubst_decomp_names before trying to tsubst_init the initializer; for valid code it should make no difference, because the initializer shouldn't refer to the decomp names, but for invalid code it matters.
[Bug target/86752] [9 Regression] FAIL: gcc.target/i386/avx2-cvt-2.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86752 Sebastian Peryt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||speryt at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Sebastian Peryt --- Duplicate of PR86745 *** This bug has been marked as a duplicate of bug 86745 ***
[Bug target/86745] [9 regression] gcc.target/i386/avx-cvt-2.c etc. FAIL on 64-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86745 Sebastian Peryt changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #1 from Sebastian Peryt --- *** Bug 86752 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/86835] [8/9 Regression] Bogus "is used uninitialized" warning with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86835 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |8.3 --- Comment #2 from Jakub Jelinek --- Started with r255141.
[Bug tree-optimization/86835] [8/9 Regression] Bogus "is used uninitialized" warning with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86835 --- Comment #3 from Jakub Jelinek --- Reduced testcase: void foo (int n, double *x, double *y) { int i; double b = y[4]; for (i = 0; i < n; ++i) y[3] += __builtin_tanh (x[i] / b); y[0] /= b; y[1] /= b * b; y[2] /= b; }
[Bug tree-optimization/86835] [8/9 Regression] Bogus "is used uninitialized" warning with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86835 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 44500 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44500&action=edit gcc9-pr86835.patch Untested fix. There was a thinko, in the gsi = *def_gsi; gsi_insert_after (def_gsi, new_stmt, GSI_NEW_STMT); case doing: gsi_insert_before (&gsi, new_square_stmt, GSI_SAME_STMT); results exactly in new_square_stmt being two stmts before new_stmt, when it should be after it (i.e. def_gsi points to some stmt, new_stmt is inserted after it and new_square_stmt before it.
[Bug other/86834] [9 regression] several tests fail with ICE starting with r263245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86834 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- From what I see, that commit has been reverted in r263252.
[Bug c++/86823] [6/7/8/9 Regression] private member template struct/class is publicly accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86823 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-03 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Bisection points to r231354.
[Bug libstdc++/86842] New: Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 Bug ID: 86842 Summary: Allow run-time checks of pre- and postconditions Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: fiesh at zefix dot tv Target Milestone: --- Preface: A rather hard-to-find set of bugs is that introduced by violating run-time preconditions imposed by certain functions. For example, failing to satisfy the Compare requirement for std::sort can lead to tricky problems ranging from segmentation faults to programs just running fine and sometimes doing something not quite expected. It would be great if there was a means to activate run-time assertions on these preconditions, as well as on postconditions. In terms of http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0788r3.pdf , everything listed as "Expects:" and "Ensures:" could be checked by a run-time check. Since in general checking a sentence with n universal quantifiers will result in O(N^n) many operations, it might be meaningful to separate those by different macros, allowing the user control over the amount of complexity degradation they allow for their debug build. In addition, checks whose complexity is within the algorithm's complexity class already might be enabled in Debug Mode Lite by default. (This extends https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60519 )
[Bug libstdc++/86842] Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=60519, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=56109 Severity|normal |enhancement --- Comment #1 from Jonathan Wakely --- (In reply to fiesh from comment #0) > It would be great if there was a means to activate run-time assertions on > these preconditions, as well as on postconditions. In terms of > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0788r3.pdf , > everything listed as "Expects:" and "Ensures:" could be checked by a > run-time check. Not everything. Some Expects preconditions cannot be tested (e.g. that pointer points to an array of at least N objects). > Since in general checking a sentence with n universal quantifiers will > result in O(N^n) many operations, it might be meaningful to separate those > by different macros, allowing the user control over the amount of complexity > degradation they allow for their debug build. That sounds like a maintenance nightmare.
[Bug libstdc++/86843] New: Allow separating debug mode into ABI-changing part and rest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86843 Bug ID: 86843 Summary: Allow separating debug mode into ABI-changing part and rest Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: fiesh at zefix dot tv Target Milestone: --- Right now, the debug mode changes the ABI. Thus everything that is linked, including libraries, needs to be compiled using debug mode, making it more difficult to use. It would be great if there were separate defines for activating the ABI changing parts as well as everything not changing the ABI (but possibly violating complexity guarantees, for example). The latter would probably be suitable for almost all debug builds of projects using libstd++.
[Bug c++/86823] [6/7/8/9 Regression] private member template struct/class is publicly accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86823 --- Comment #2 from Jakub Jelinek --- Confirmed by commenting out the two: tentative_firewall firewall (parser); lines and the testcase is rejected again.
[Bug libstdc++/60519] Debug mode should check comparators for irreflexivity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60519 --- Comment #6 from Jonathan Wakely --- The irreflexivity checks I originally asked for are done - do we want to keep this open for more extensive checks, or close as FIXED?
[Bug libstdc++/86843] Allow separating debug mode into ABI-changing part and rest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86843 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-03 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Jonathan Wakely --- So retain all the debug checks in algorithms and in basic_string, but don't replace std::vector with __gnu_debug::vector and so on. Seems like a good idea.
[Bug other/86834] [9 regression] several tests fail with ICE starting with r263245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86834 --- Comment #2 from Thomas Preud'homme --- Thanks for the detailed report.
[Bug libstdc++/86842] Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 --- Comment #2 from fiesh at zefix dot tv --- > Not everything. Some Expects preconditions cannot be tested (e.g. that > pointer points to an array of at least N objects). True. I suppose it's sufficient to have that memory accessed (somehow explicitly or via other checks), allowing sanitizers to catch bugs here. > That sounds like a maintenance nightmare. Can you elaborate? There could also be a define like I_DONT_KNOW_COMPLEXITY_CLASS that sets the exponent n of the O(N^n)?
[Bug c++/86738] [8/9 Regression] gcc 8.2: Internal compiler error memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86738 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Reduced testcase: struct S { int s; }; unsigned char a[20]; void foo () { __builtin_memcpy (&a[15], &a[(unsigned) (__UINTPTR_TYPE__) &((S *) 0)->s], 2); // __builtin_memcpy (&a[15], &a[(unsigned) __builtin_offsetof (S, s)], 2); } You really should just use offsetof, instead of poor man's attempts at it. That said, g++ should not crash on it.
[Bug libstdc++/86842] Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 --- Comment #3 from Jonathan Wakely --- (In reply to fiesh from comment #2) > > Not everything. Some Expects preconditions cannot be tested (e.g. that > > pointer points to an array of at least N objects). > > True. I suppose it's sufficient to have that memory accessed (somehow > explicitly or via other checks), allowing sanitizers to catch bugs here. > > > That sounds like a maintenance nightmare. > > Can you elaborate? There could also be a define like > I_DONT_KNOW_COMPLEXITY_CLASS that sets the exponent n of the O(N^n)? Every additional knob that users can turn increases the implementation burden and the testing required for proper coverage. So I'm strongly opposed to that part of the suggestion. Either you get all the ABI-preserving debug checks, or none.
[Bug tree-optimization/86732] Potential nullptr dereference does not propagate knowledge about the pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86732 Antony Polukhin changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #9 from Antony Polukhin --- (In reply to Jeffrey A. Law from comment #8) > I wouldn't object to that. In fact I thought we kicked that around along > with an option to remove path leading to the undefined behavior completely. > But it's not something I'm likely to work on. IMO you will need this flag anyway with the "C++20 Contracts" feature to turn contract violations into UB/trap/HandlerCall/terminate/...
[Bug target/86838] [9 Regression] ICE in gen_aarch64_frecpe, at ./insn-opinit.h:571
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86838 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #2 from rsandifo at gcc dot gnu.org --- (In reply to ktkachov from comment #1) > Confirmed, appeared very recently. I suspect it's fallout from r263251 ? Oops, yes.
[Bug c++/86738] [8/9 Regression] gcc 8.2: Internal compiler error memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86738 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 44501 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44501&action=edit gcc9-pr86738.patch Untested fix.
[Bug libstdc++/86842] Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 --- Comment #4 from fiesh at zefix dot tv --- > So I'm strongly opposed to that part of the suggestion. Either you get all > the ABI-preserving debug checks, or none. Checking all (possible) preconditions without any limit on the introduced complexity might not be possible within reasonable time. Checking transitivity naively is O(N^3). Maybe there's a better way to check something is a strict weak ordering, but in general there might always be a sentence whose veracity cannot be established more efficiently. So if the library wanted to provide checks for every precondition that can be verified (which was my original proposition), I don't see how it's possible meaningfully without any restriction on the computational efforts spent.
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #14 from Jakub Jelinek --- Can't reproduce, either with gcc 8.2.0, or current 8.2.1, or latest trunk: /d/gcc-8.2.0/objdir/gcc/gfortran -B /d/gcc-8.2.0/objdir/gcc/ -march=skylake-avx512 -Ofast -o pr86735{,.f90} -B /d/gcc-8.2.0/objdir/x86_64-pc-linux-gnu/libgfortran/.libs/ -B /d/gcc-8.2.0/objdir/x86_64-pc-linux-gnu/libgfortran/ -B /d/gcc-8.2.0/objdir/x86_64-pc-linux-gnu/libquadmath/.libs/ -Wl,-rpath,../x86_64-pc-linux-gnu/libgfortran/.libs/; /usr/src/sde/sde64 -- ./pr86735 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Perhaps sde64 behaves differently from real HW? Tried also -O3 -fstack-arrays, -mprefer-vector-width={128,256,512}, but everything works.
[Bug c++/86706] [8/9 Regression] ICE in build_base_path, at cp/class.c:294
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86706 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Fri Aug 3 15:10:32 2018 New Revision: 263293 URL: https://gcc.gnu.org/viewcvs?rev=263293&root=gcc&view=rev Log: PR c++/86706 * class.c (build_base_path): Use currently_open_class. * g++.dg/template/pr86706.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/pr86706.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/86842] Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 --- Comment #5 from Jonathan Wakely --- Checking all possible preconditions isn't practical anyway, so isn't going to happen, so we don't need knobs to control that. Not everything can be checked, at some point users need to write correct code.
[Bug libstdc++/86842] Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 --- Comment #6 from Jonathan Wakely --- In fact I'm not really sure there's anything concrete that can be done here. "Check stuff!" isn't very helpful. We already check stuff. Specific suggestions for additional checks are useful. Overly general requests to check everything are not useful, and so the bug report might as well be closed. Nobody's going to work on "check everything everywhere and make it all configurable". Instead of inventing gcc-specific mechanisms it would seem prudent to do something based on http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0542r5.html but we have no plans for using that in libstdc++ at this time.
[Bug c/86690] [PATCH] Duplicate field in anonymous union causes infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86690 --- Comment #3 from Joseph S. Myers --- Author: jsm28 Date: Fri Aug 3 15:25:35 2018 New Revision: 263294 URL: https://gcc.gnu.org/viewcvs?rev=263294&root=gcc&view=rev Log: Avoid infinite loop with duplicate anonymous union fields (PR c/86690). If a struct contains an anonymous union and both have a field with the same name, detect_field_duplicates_hash() will replace one of them with NULL. If compilation doesn't stop immediately, it may later call lookup_field() on the union, which falsely assumes the union's LANG_SPECIFIC array is sorted, and may loop indefinitely because of this. 2018-08-03 Bogdan Harjoc PR c/86690 gcc/c: * c-typeck.c (lookup_field): Do not use TYPE_LANG_SPECIFIC after errors. gcc/testsuite: * gcc.dg/union-duplicate-field.c: New test. Added: trunk/gcc/testsuite/gcc.dg/union-duplicate-field.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/86690] [PATCH] Duplicate field in anonymous union causes infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86690 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #4 from Joseph S. Myers --- Fix committed for GCC 9.
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #15 from H.J. Lu --- I can no longer reproduce it under kernel 4.17.11.
[Bug target/86828] [6/7 Regression] wrong-code bug with "-march=knl -Ofast" (invalid memory reference)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86828 --- Comment #6 from H.J. Lu --- My machine is Intel Xeon Platinum 8180 and I have no problem under kernel 4.17.11.
[Bug tree-optimization/86844] New: wrong code generation cause by store merging pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86844 Bug ID: 86844 Summary: wrong code generation cause by store merging pass Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: krebbel at gcc dot gnu.org Target Milestone: --- Created attachment 44502 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44502&action=edit Reduced testcase Compiling the attached testcase with -O2 results in the following code: movzbl 4(%rdi), %eax movl$33024, 8(%rdi) movb%al, 10(%rdi) 33024 -> 0 0 129 0 The store of 222 gets optimized away. Without store merging: movzbl 4(%rdi), %eax movl$0, 8(%rdi) movb$-34, 11(%rdi) movb$-127, 9(%rdi) movb%al, 10(%rdi) The original order of stores: a->b.wd0.u4i = 0; a->b.wd0.s2.w = 222; a->b.wd0.s2.y = 129; a->b.wd0.s2.z = a->f.wd1.s2.z; coalesce_immediate_stores first reorders the stores according to its bit positions: a->b.wd0.u4i = 0; a->b.wd0.s2.y = 129; a->b.wd0.s2.z = a->f.wd1.s2.z; a->b.wd0.s2.w = 222; It then merges the first and the second and has to end the group seeing the third. So the last ends up in its own group. Emitting the stores in the original order makes the 222 store dead. The first two should not be merged. coalesce_immediate_stores already tries to detect cases where stores later in the chain might get invalidated by merging early stores but it also assumes that if the later store also stores a constant it will be possible to merge it as well. However, in this case the non-constant store in between prevents this. Store merging pass output: ;; Function f (f, funcdef_no=0, decl_uid=1922, cgraph_uid=1, symbol_order=0) Processing basic block <2>: Starting new chain with statement: a_3(D)->b.wd0.u4i = 0; The base object is: a_3(D) Recording immediate store from stmt: a_3(D)->b.wd0.s2.w = 222; Recording immediate store from stmt: a_3(D)->b.wd0.s2.y = 129; Recording immediate store from stmt: a_3(D)->b.wd0.s2.z = _1; stmt causes chain termination: return; Attempting to coalesce 4 stores in chain New store group Store 0: bitsize:32 bitpos:64 val:0 Store 1: bitsize:8 bitpos:72 val:129 After writing 0 of size 32 at position 0 the merged value contains 00 00 00 00 the merged mask contains 00 00 00 00 After writing 129 of size 8 at position 8 the merged value contains 00 81 00 00 the merged mask contains 00 00 00 00 New store group Store 2: bitsize:8 bitpos:80 val:_1 New store group Store 3: bitsize:8 bitpos:88 val:222 Coalescing successful! Merged into 1 stores New sequence of 1 stores to replace old one of 2 stores # .MEM_6 = VDEF <.MEM_5> MEM[(union *)a_3(D) + 8B] = 33024; Merging successful! f (struct bar * a) { unsigned char _1; [local count: 1073741825]: a_3(D)->b.wd0.s2.w = 222; MEM[(union *)a_3(D) + 8B] = 33024; _1 = a_3(D)->D.1919.f.wd1.s2.z; a_3(D)->b.wd0.s2.z = _1; return; }
[Bug tree-optimization/86844] wrong code generation cause by store merging pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86844 --- Comment #1 from Andreas Krebbel --- Created attachment 44503 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44503&action=edit experimental patch This patch adds a check to check_no_overlap which rejects overlaps if it has seen a non-constant store in between. This fixes the testcase for me.
[Bug tree-optimization/86841] ICE in /home/marxin/Programming/gcc/gcc/tree-vrp.c:1325 with graphite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86841 --- Comment #1 from Martin Sebor --- I don't apparently have this enabled in my builds so I can't readily confirm this error -- I get f951: sorry, unimplemented: Graphite loop optimizations cannot be used (isl is not available) (-fgraphite, -fgraphite-identity, -floop-nest-optimize, -floop-parallelize-all). I have isl-devel installed so I'm not sure what else I need to do to enable it. I'll see if building with ISL downloaded and installed by download_prerequisites enables it (please let me know if there's some trick to making this work.) But beyond that, I doubt this is a problem in the sprintf pass itself. More likely some interaction between the range DOM walker it uses (which sets ranges for statements) and VRP.
[Bug tree-optimization/86844] wrong code generation cause by store merging pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86844 Andreas Krebbel changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 Severity|normal |major
[Bug target/86831] three failures in gfortran.fortran-torture with "-Ofast -march=native" on skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86831 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-03 Ever confirmed|0 |1 --- Comment #6 from H.J. Lu --- On Intel Xeon Platinum 8180 under kerne 4.17.11-200, I got PASS: gfortran.fortran-torture/execute/in-pack.f90 execution, -Ofast -march=native FAIL: gfortran.fortran-torture/execute/intrinsic_nearest.f90 execution, -Ofast -march=native FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution, -Ofast -march=native
[Bug target/86831] three failures in gfortran.fortran-torture with "-Ofast -march=native" on skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86831 --- Comment #7 from H.J. Lu --- (In reply to janus from comment #5) > However, in-pack.f90 is the only one that is made to fail by the combination > of -Ofast and -march=skylake-avx512. I think it's the same problem as PR > 86735 (at least it behaves in the same way). > Which kernel are you using?
[Bug jit/86845] New: libgccjit.so.0.0.1 build error with in-tree isl: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86845 Bug ID: 86845 Summary: libgccjit.so.0.0.1 build error with in-tree isl: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- While trying to build GCC with enough support to debug bug 86841 (apparently the ISL installed on the machine isn't good enough), I downloaded and installed the latest prerequisites, configured GCC via 'configure --enable-host-shared --enable-languages=all' and got the error below. This used to work fine. /usr/bin/ld: /opt/notnfs/msebor/build/gcc-git/./isl/.libs/libisl.a(isl_val_gmp.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC /opt/notnfs/msebor/build/gcc-git/./isl/.libs/libisl.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status /opt/notnfs/msebor/src/gcc/git/gcc/jit/Make-lang.in:97: recipe for target 'libgccjit.so.0.0.1' failed make[3]: *** [libgccjit.so.0.0.1] Error 1 make[3]: *** Waiting for unfinished jobs
[Bug libstdc++/86846] New: [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86846 Bug ID: 86846 Summary: [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 This causes many tests to fail: spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc -B/test/gnu/gcc/objdir/./gc c -nostdinc++ -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src -L/tes t/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs -L/test/gnu/gcc/objd ir/hppa64-hp-hpux11.11/libstdc++-v3/libsupc++/.libs -B/opt/gnu64/gcc/gcc-9/hppa6 4-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-9/hppa64-hp-hpux11.11/lib/ -isystem /op t/gnu64/gcc/gcc-9/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-9/hppa 64-hp-hpux11.11/sys-include -fchecking=1 -B/test/gnu/gcc/objdir/hppa64-hp-hpux11 .11/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sect ions -fdata-sections -g -O2 -DLOCALEDIR="." -nostdinc++ -I/test/gnu/gcc/objdir/h ppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/test/gnu/gcc/objd ir/hppa64-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/lib supc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/test/gnu/gcc/gcc/lib stdc++-v3/testsuite/util /test/gnu/gcc/gcc/libstdc++-v3/testsuite/17_intro/frees tanding.cc -lsupc++ -fvtable-verify=none -fno-diagnostics-show-caret -fdiagnosti cs-color=never ./libtestc++.a -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc ++-v3/src/filesystem/.libs -lm -o ./freestanding.exe ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in file /test/gnu/gcc/obj dir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs/libstdc++.sl 1 warnings. output is: ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in file /test/gnu/gcc/obj dir/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs/libstdc++.sl 1 warnings. FAIL: 17_intro/freestanding.cc (test for excess errors)
[Bug tree-optimization/86847] New: [9 Regression] Switch code size growth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86847 Bug ID: 86847 Summary: [9 Regression] Switch code size growth Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ka6ash at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- I noticed that the size of code has grown in switch statements between 8.1.0 and trunk. For the code shown below, gcc-trunk generates 2 jumps for each switch statement (18 in total) when gcc-8.1.0 only 11. The difference appears at switchlower1 pass. As I understand, gcc-8 prunes redundant tests when gcc-9 doesn't and instead relies on further tree optimizations (https://gcc.gnu.org/ml/gcc-patches/2017-09/msg00891.html). But the optimizations cannot manage with it as well as pruning in gcc-8 can and size grows. Enabling -O2 does not change the situation significantly. int cipher_to_alg(int cipher) { switch (cipher) { case 8: return 2; case 16: return 3; case 32: return 4; case 64: return 6; case 256: return 9; case 512: return 10; case 2048: return 11; case 4096: return 12; case 8192: return 13; } return 0; } arm-none-eabi-gcc-8.1.0 cipher.c -Os -S cipher_to_alg: cmp r0, #256 beq .L6 bgt .L3 cmp r0, #16 beq .L7 bgt .L4 cmp r0, #8 moveq r0, #2 .L15: movne r0, #0 bx lr .L4: cmp r0, #32 beq .L9 cmp r0, #64 moveq r0, #6 b .L15 .L3: cmp r0, #2048 beq .L11 bgt .L5 cmp r0, #512 moveq r0, #10 b .L15 .L5: cmp r0, #4096 beq .L13 cmp r0, #8192 moveq r0, #13 b .L15 .L6: mov r0, #9 bx lr .L7: mov r0, #3 bx lr .L9: mov r0, #4 bx lr .L11: mov r0, #11 bx lr .L13: mov r0, #12 bx lr arm-none-eabi-gcc-9.0.0 cipher.c -Os -S cipher_to_alg: cmp r0, #256 bgt .L2 beq .L8 cmp r0, #16 bgt .L4 beq .L9 cmp r0, #8 bgt .L20 bne .L20 mov r0, #2 bx lr .L4: cmp r0, #32 bgt .L5
[Bug target/86795] mn10300 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86795 --- Comment #1 from Jeffrey A. Law --- Author: law Date: Fri Aug 3 17:39:00 2018 New Revision: 263296 URL: https://gcc.gnu.org/viewcvs?rev=263296&root=gcc&view=rev Log: PR target/86795 * config/mn10300/mn10300.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_safe_value_not_needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mn10300/mn10300.c
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86795, which changed state. Bug 86795 Summary: mn10300 port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86795 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/86795] mn10300 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86795 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #2 from Jeffrey A. Law --- Fixed on the trunk.
[Bug tree-optimization/86848] New: ARM: (-O3 -march=armv7-a -mfpu=neon-vfpv4) vst1 wrong alignment for `vst1.64 {d16-d17}, [r4 :64]` before function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86848 Bug ID: 86848 Summary: ARM: (-O3 -march=armv7-a -mfpu=neon-vfpv4) vst1 wrong alignment for `vst1.64 {d16-d17}, [r4 :64]` before function call Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: cjd at cjdns dot fr Target Milestone: --- Created attachment 44504 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44504&action=edit .i file which can be compiled to an o file to observe the vst1.64 Comments: Using -O3, and -mfpu=neon-vfpv4, I'm getting a wrong alignment when pushing local variables to the stack before a function call. Unfortunately I was not able to reproduce this with a simple code snippet but I have an .i file which produces the assembly and you can see the effect by doing: git clone git://github.com/cjdelisle/cjdns && cd cjdns git checkout crashey CC=arm-linux-gnueabihf-gcc-8 AR=arm-linux-gnueabihf-gcc-ar-8 RANLIB=arm-linux-gnueabihf-gcc-ranlib-8 CFLAGS="-marm -march=armv7-a -mfpu=neon-vfpv4" CROSS=1 NO_LTO=1 VERBOSE=1 ./do ## copying ./build_linux/test_testcjdroute_c to the ARM device and running gdb ./test_testcjdroute_c -ex 'r RouteGen_test' If you only want to see the assembler dump, you can download the attached .i file and compile it with the provided compile command and then gdb the .o file and disassemble sockaddrToPrefix6. Compiler version (default from Ubuntu): root@dickbutt:/opt/cjdns# arm-linux-gnueabihf-gcc-8 -v Using built-in specs. COLLECT_GCC=arm-linux-gnueabihf-gcc-8 COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/8/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8-20180414-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --with-as=/usr/bin/arm-linux-gnueabihf-as --with-ld=/usr/bin/arm-linux-gnueabihf-ld --program-suffix=-8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include Thread model: posix gcc version 8.0.1 20180414 (experimental) [trunk revision 259383] (Ubuntu 8-20180414-1ubuntu2) Relevant compile command: arm-linux-gnueabihf-gcc-8 -c -x cpp-output -o build_linux/tunnel_RouteGen_c.o -std=c99 -Wall -Wextra -Werror -Wno-pointer-sign -Wmissing-prototypes -pedantic -D linux=1 -D CJD_PACKAGE_VERSION="cjdns-v20.2-39-g5d561d65-dirty" -Wno-unused-parameter -D Log_DEBUG -g -D NumberCompress_TYPE=v3x5x8 -D Identity_CHECK=1 -D Allocator_USE_CANARIES=1 -D PARANOIA=1 -DHAS_ETH_INTERFACE=1 -fPIE -marm -march=armv7-a -mfpu=neon-vfpv4 -marm -march=armv7-a -mfpu=neon-vfpv4 -marm -march=armv7-a -mfpu=neon-vfpv4 -D_FORTIFY_SOURCE=2 -fno-stack-protector -fstack-protector-all -Wstack-protector -O3 build_linux/tunnel_RouteGen_c.o.i Debugger output: root@dirtysanchez:/home/user# gdb -q ./test_testcjdroute_c -ex 'r RouteGen_test' Reading symbols from ./test_testcjdroute_c...done. Starting program: /home/user/test_testcjdroute_c RouteGen_test [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". 1533318603 DEBUG RouteGen_test.c:108 Forward Program received signal SIGBUS, Bus error. sockaddrToPrefix6 (sa=sa@entry=0xbeffeb98, allocator=) at tunnel/RouteGen.c:164 164 Assert_true(pfx > -1); (gdb) disassemble Dump of assembler code for function sockaddrToPrefix6: 0x0042a49c <+0>: ldr r3, [pc, #308] ; 0x42a5d8 0x0042a4a0 <+4>: ldr r2, [pc, #308] ; 0x42a5dc 0x0042a4a4 <+8>: add r3, pc, r3 0x0042a4a8 <+12>:push{r4, r5, r6, r7, r8, lr} 0x0042a4ac <+16>:sub sp, sp, #40 ; 0x28 0x0042a4b0 <+20>:ldr r6, [r3, r2] 0x0042a4b4 <+24>:mov r4, r1 0x0042a4b8 <+28>:add r1, sp, #12 0x0042a4bc <+32>:mov r5, r0 0x0042a4c0 <+36>:ldr r3, [r6] 0x0042a4c4 <+40>:str r3, [sp, #36] ; 0x24 0x0042a4c8 <+44>:bl 0x4102a0 0x0042a4cc <+48>:cmp r0, #16 0x0042a4d0 <+5
[Bug tree-optimization/86848] ARM: (-O3 -march=armv7-a -mfpu=neon-vfpv4) vst1 wrong alignment for `vst1.64 {d16-d17}, [r4 :64]` before function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86848 --- Comment #1 from Caleb James DeLisle --- This issue also reproduces on 6.3.0: root@dirtysanchez:/home/user# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/6/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
[Bug tree-optimization/86848] ARM: (-O3 -march=armv7-a -mfpu=neon-vfpv4) vst1 wrong alignment for `vst1.64 {d16-d17}, [r4 :64]` before function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86848 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- Hmm, the allocator Allocator__calloc is not returning the "correct" alignment pointer for the type used here. 0x0042a534 <+152>: bl 0x405b74 0x0042a538 <+156>: vldrd16, [sp, #16] 0x0042a53c <+160>: vldrd17, [sp, #24] 0x0042a540 <+164>: vrev64.8q8, q8 0x0042a544 <+168>: mov r4, r0 0x0042a548 <+172>: mov r0, r5 0x0042a54c <+176>: vst1.64 {d16-d17}, [r4 :64] r4 here is from the allocator. And if I read this correctly, then Allocator__calloc is incorrect. struct Prefix6* out = Allocator__calloc((alloc),(sizeof(struct Prefix6)),(1),"RouteGen.c",161); out->highBits = ((uint64_t)__builtin_bswap64(((uint64_t)(longs.highBits_be; out->lowBits = ((uint64_t)__builtin_bswap64(((uint64_t)(longs.lowBits_be; int pfx = Sockaddr_getPrefix(sa); So it is doing a store into out (the high and low bits fields). So this memory needs to be 8 byte aligned as the alignment of struct Prefix6 is 8 bytes due to the uint64_t. So this is invalid.
[Bug tree-optimization/86848] ARM: (-O3 -march=armv7-a -mfpu=neon-vfpv4) vst1 wrong alignment for `vst1.64 {d16-d17}, [r4 :64]` before function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86848 --- Comment #3 from Andrew Pinski --- The problem is in https://github.com/cjdelisle/cjdns/blob/crashey/memory/BufferAllocator.c /* Define alignment as the size of a pointer which is usually 4 or 8 bytes. */ #define ALIGNMENT sizeof(char*) That should be different; maybe sizeof(uint64_t) or __alignof__(uint64_t). There might be a C99/C14 macro that you could use.
[Bug tree-optimization/86848] ARM: (-O3 -march=armv7-a -mfpu=neon-vfpv4) vst1 wrong alignment for `vst1.64 {d16-d17}, [r4 :64]` before function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86848 --- Comment #4 from Caleb James DeLisle --- Very sorry to have bothered you and thank you for your time.
[Bug fortran/86837] Optimization breaks an unformatted read with implicit loop on Mac OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86837 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #1 from Harald Anlauf --- If I add "-fno-frontend-optimize", the test case runs properly. There have been other cases where front-end optimization fell over nested loops. You were lucky to find another one that's not yet covered.
[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523 --- Comment #7 from David Malcolm --- Author: dmalcolm Date: Fri Aug 3 18:38:13 2018 New Revision: 263298 URL: https://gcc.gnu.org/viewcvs?rev=263298&root=gcc&view=rev Log: Add fix-it hint for missing return statement in assignment operators (PR c++/85523) gcc/cp/ChangeLog: PR c++/85523 * decl.c: Include "gcc-rich-location.h". (add_return_star_this_fixit): New function. (finish_function): When warning about missing return statements in functions returning non-void, add a "return *this;" fix-it hint for assignment operators. gcc/testsuite/ChangeLog: PR c++/85523 * g++.dg/pr85523.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr85523.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from David Malcolm --- Implemented in trunk (for gcc 9) by r263298.
[Bug c++/86849] New: g++ applies guaranteed copy elision to delegating construction, resulting in miscompiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86849 Bug ID: 86849 Summary: g++ applies guaranteed copy elision to delegating construction, resulting in miscompiles Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: richard-gccbugzilla at metafoo dot co.uk Target Milestone: --- Live testcase: https://godbolt.org/g/AKn7j7 For posterity: #include struct A { A() {} A(int); ~A() {} int n; char k; }; A f(); A::A(int) : A(f()) {} A f() { A result; std::memset(&result, 0, sizeof(A)); return result; // (nrvo) } struct B { char x, y, z; }; struct X : A, virtual B { // B is in A's tail padding X() : B{1, 2, 3}, A(4) {} }; char test() { X x; return x.x; // should return 1 } Here, GCC uses f() to directly construct the A base class of the X object, and that tramples over A's tail padding (which contains the B virtual base class of X, which has already been initialized). It's not correct to apply guaranteed copy elision to a delegating construction, just like it's not correct to apply it to a base class construction -- not even in the C1 constructor variant, due to [[no_unique_address]].
[Bug c/86850] New: ubsan: runtime error: member call on null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86850 Bug ID: 86850 Summary: ubsan: runtime error: member call on null pointer Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- This C code: struct { long a[0] } b; c, d, k; long l() { long e, g, h, j; int f, i; for (; i < 4; i++) j = h < 0; e += i >> i + j ^ j; g -= h + j ^ j; for (i--; i; i++) { j = -(h < 0); e += i >> i + j ^ g >> 1; g -= h >> 1 + j ^ j; h -= c + j ^ j; } return f << 7 + e; } m() { if (d) if (k) b.a[1] = b.a[0] = l() - 4; } when compiled by a recent ubsan version of trunk, does this: $ ~/gcc/results.263285.ubsan/bin/gcc -c -O3 -std=c89 -w bug453.c ../../trunk/gcc/vec.h:1688:5: runtime error: member call on null pointer of type 'struct vec' It is fine at lower optimise levels: $ ~/gcc/results.263285.ubsan/bin/gcc -c -O2 -std=c89 -w bug453.c $
[Bug c++/86849] g++ applies guaranteed copy elision to delegating construction, resulting in miscompiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86849 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-03 Ever confirmed|0 |1
[Bug libstdc++/86846] [9 Regression] ld: (Warning) Unsatisfied symbol "__atomic_exchange_8" in libstdc++.sl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86846 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-03 Ever confirmed|0 |1
[Bug libstdc++/60519] Debug mode should check comparators for irreflexivity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60519 François Dumont changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #7 from François Dumont --- Yes, we can consider this as fixed. I don't even think that I will eventually try to add the antisymmetry check.
[Bug tree-optimization/86851] New: missing -Wformat-overflow on %s with a constant string plus variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86851 Bug ID: 86851 Summary: missing -Wformat-overflow on %s with a constant string plus variable offset Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Even though it's possible to determine the range of lengths of the constant string in the sprintf call below the sprintf pass fails to do so and so misses the buffer overflow and also emits suboptimal code. The problem is in the string_constant function failing to determine the string the &a[i] expression refers to. The expression the function sees is SSA_NAME (L"123...") + offset but it only handles ADDR_EXPR, PLUS_EXPR/POINTER_PLUS_EXPR, and DECL. $ cat d.c && gcc -O2 -S -Wall -fdump-tree-printf-return-value=/dev/stdout d.c static const char a[] = "123456789"; char d[4]; void f (int i) { if (i > 2) i = 2; __builtin_sprintf (d, "%s", &a[i]); } ;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=2) d.c:10: __builtin_sprintf: objsize = 4, fmtstr = "%s" Directive 1 at offset 0: "%s" Result: 0, 0, -1, 9223372036854775807 (0, 0, -1, -1) Directive 2 at offset 2: "", length = 1 f (int i) { const char * _1; sizetype _2; [local count: 1073741825]: i_6 = MIN_EXPR ; _2 = (sizetype) i_6; _1 = &a + _2; __builtin_strcpy (&d, _1); return; }
[Bug libstdc++/86852] New: map and unordered_map wrong deduction guides for inilializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86852 Bug ID: 86852 Summary: map and unordered_map wrong deduction guides for inilializer_list Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mickey.veksler at gmail dot com Target Milestone: --- According to https://en.cppreference.com/w/cpp/container/unordered_map/deduction_guides Deduction guides for unodrered_map: template, class Pred = std::equal_to, class Alloc = std::allocator>> unordered_map(std::initializer_list>, typename /*see below*/::size_type = /*see below*/, Hash = Hash(), Pred = Pred(), Alloc = Alloc()) -> unordered_map; Note that the guide is for std::pair, i.e., the key is const. In libstdc++'s unodered_map: unordered_map(initializer_list>, typename unordered_map::size_type = {}, _Hash = _Hash(), _Pred = _Pred(), _Allocator = _Allocator()) -> unordered_map<_Key, _Tp, _Hash, _Pred, _Allocator>; Note that pair<_Key, _Tp>, i.e., the key is not const. This breaks unordered_map and map deduction guides: #include #include int main() { std::unordered_map m1(std::initializer_list< std::pair>({{1, 2}, {2, 3}})); } This fails with: : In function 'int main()': :5:69: error: class template argument deduction failed: std::pair>({{1, 2}, {2, 3}})); However, if const is removed from the key: This breaks unordered_map and map deduction guides: #include #include int main() { std::unordered_map m1(std::initializer_list< std::pair< int, int>>({{1, 2}, {2, 3}})); } Deduction guide works, but it is unusable: : In function 'int main()': :5:64: error: no matching function for call to 'std::unordered_map::unordered_map(std::initializer_list >)' std::pair< int, int>>({{1, 2}, {2, 3}})); = The only way to make this work in gcc is std::unordered_map m{std::pair{1,2}, {3,4}}; But this does not seem to be correct.
[Bug libstdc++/86842] Allow run-time checks of pre- and postconditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86842 fiesh at zefix dot tv changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from fiesh at zefix dot tv --- "Concrete stuff" that could be done is ensuring Compare for std::sort, but then I feel this might make the ticket too specific. Even though I'm not entirely convinced this is actually a bad idea, I'll close the ticket seeing there seems to be no support for it.
[Bug tree-optimization/80537] missing -Wformat-overflow on POSIX %C conversion specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80537 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug tree-optimization/86853] New: sprintf optimization for wide strings doesn't account for conversion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86853 Bug ID: 86853 Summary: sprintf optimization for wide strings doesn't account for conversion failure Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- The handling of wide character and string constants in the sprintf pass fails to consider the possibility of conversion failure. As a result, it sets the return value to a non-negative range when it should avoid setting it instead. (Pointed out in https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00275.html). $ cat d.c && gcc -O2 -Wall -fdump-tree-optimized=/dev/stdout d.c && ./a.out __WCHAR_TYPE__ ws[] = L"\u"; int main (void) { int n0 = __builtin_snprintf (0, 0, "%S", L"\u"); int n1 = __builtin_snprintf (0, 0, "%S", ws); __builtin_printf ("%i == %i\n", n0, n1); if (n0 != n1) __builtin_abort (); } ;; Function main (main, funcdef_no=0, decl_uid=1899, cgraph_uid=1, symbol_order=1) (executed once) main () { int n1; [local count: 1073741825]: n1_5 = __builtin_snprintf (0B, 0, "%S", &ws); __builtin_printf ("%i == %i\n", 1, n1_5); if (n1_5 != 1) goto ; [0.00%] else goto ; [99.96%] [count: 0]: __builtin_abort (); [local count: 1073312327]: return 0; } 1 == -1 Aborted (core dumped)
[Bug tree-optimization/86853] sprintf optimization for wide strings doesn't account for conversion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86853 Martin Sebor changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-08-03 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||7.3.0, 8.2.0, 9.0
[Bug rtl-optimization/86854] New: crash on stack unwinding with reorder-blocks-and-partition + linker code folding + C++ exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86854 Bug ID: 86854 Summary: crash on stack unwinding with reorder-blocks-and-partition + linker code folding + C++ exceptions Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: oremanj at mit dot edu Target Milestone: --- With -freorder-blocks-and-partition in GCC 8 (but not in 7.x), GCC shows a tendency to move exception-throwing C++ code into .cold fragments. The resulting fragments are often identical between different functions that throw the same type of exception, and thus will get merged by a linker's "identical code folding" feature such as gold's --icf=safe. If the functions from which the identical .cold fragments were split off have different stack layouts, the merging will lead to misbehavior during stack unwinding, since the single shared PC of the __cxa_throw call in the merged .cold fragment can't be associated with the multiple different stack layouts of the multiple functions that jump to it. It's not immediately clear to me whether it's GCC or gold that should be doing something to prevent this, but GCC seems to be much better positioned to identify the danger, and the documentation for -freorder-blocks-and-partition says suggestive things about inapplicability to exception-handling scenarios, so I'm reporting here first. This is an x86_64 Linux system with GCC from SVN 20180719 (r262861), very close to 8.2 RC, and none of the few commits between there and 8.2 final appear related to the issue at hand. gold is version 1.14 from Binutils 2.29.1. Issue still appears with gold pulled from git master just now; haven't tried with a newer gcc yet. $ cat t1.cc extern "C" int random(); struct nontrivial { ~nontrivial() { (void) random(); } }; int fn1(int value) { nontrivial guard; if (value < 0) throw -value; return 0; } $ cat t2.cc extern "C" int random(); struct nontrivial { ~nontrivial() { (void) random(); } }; int fn2(int value) { // try to use a lot of registers int vals[] = {random(), random(), random(), random(), random(), random(), random(), random()}; int res = (((vals[0] + vals[1]) * (vals[2] + vals[3])) / ((vals[4] + vals[5]) * (vals[6] + vals[7]))); nontrivial guard; if (value + (res & 1) < 0) throw -value; return 0; } $ cat tm.cc extern int fn1(int); extern int fn2(int); extern "C" int puts(const char *s); int main() { try { fn1(-1); puts("didn't throw 1"); } catch (int) { puts("caught 1"); } try { fn2(-2); puts("didn't throw 2"); } catch (int) { puts("caught 2"); } } $ g++-8 -O2 -std=c++17 -freorder-blocks-and-partition -fuse-ld=gold -o t t1.cc t2.cc tm.cc $ ./t caught 1 caught 2 $ g++-8 -O2 -std=c++17 -freorder-blocks-and-partition -fuse-ld=gold -Wl,--icf=safe -o t t1.cc t2.cc tm.cc $ ./t caught 1 Segmentation fault (core dumped)
[Bug rtl-optimization/86854] crash on stack unwinding with reorder-blocks-and-partition + linker code folding + C++ exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86854 --- Comment #1 from Joshua Oreman --- To clarify, the -freorder-blocks-and-partition argument in the example invocations is superfluous (that optimization is enabled by default at -O2). With -fno-reorder-blocks-and-partition the issue is not observed even with identical code folding enabled.
[Bug rtl-optimization/86854] crash on stack unwinding with reorder-blocks-and-partition + linker code folding + C++ exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86854 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- This is a bug in gold's linker implementation of --icf=safe. The main reason is the eh/unwind information from GCC is correct for the landing location but --icf=safe does not take into account the difference in landing locations before merging them. Report this to binutils instead.
[Bug fortran/86837] Optimization breaks an unformatted read with implicit loop on Mac OS X
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86837 --- Comment #2 from Pascal --- (In reply to Harald Anlauf from comment #1) > If I add "-fno-frontend-optimize", the test case runs properly. > > There have been other cases where front-end optimization fell over > nested loops. You were lucky to find another one that's not yet covered. This option will help, I can live with the other optimizations only. Hope you can fix the problem I was so lucky to find ;>)
[Bug c/81665] Please introduce flags attribute for enums which will mimic one from C#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81665 Eric Gallager changed: What|Removed |Added CC||palves at redhat dot com --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > Confirming as an enhancement. Pedro Alves also requested this feature on the > gcc-patches mailing list: > https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00726.html cc-ing him
[Bug target/86831] three failures in gfortran.fortran-torture with "-Ofast -march=native" on skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86831 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to H.J. Lu from comment #7) > Which kernel are you using? 4.15.0-29-generic (as shipped with Ubuntu 18.04).
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #16 from janus at gcc dot gnu.org --- (In reply to H.J. Lu from comment #15) > I can no longer reproduce it under kernel 4.17.11. But five days ago you could, right? What changed in the meantime? I still see the problem with 8.2.0 and today's trunk, in the following setup: * Ubuntu 18.04, kernel 4.15.0 * Intel(R) Core(TM) i9-7980XE CPU * glibc 2.27, binutils 2.30
[Bug target/86735] [8/9 Regression] Bad wrong-code bug with "-march=skylake-avx512 -Ofast"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86735 --- Comment #17 from janus at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #14) > /usr/src/sde/sde64 -- ./pr86735 >1 2 3 4 5 6 > 7 8 9 10 11 12 13 > 14 15 16 >1 2 3 4 5 6 > 7 8 9 10 11 12 13 > 14 15 16 > Perhaps sde64 behaves differently from real HW? Huh, sounds possible. However, I see the buggy behavior also with sde64 (on the same machine where I also see it in real HW, see comment 16).