[Bug tree-optimization/94621] [9/10 Regression] GCC 9.2.1 segfaults when compiling file with -O3 since r9-5354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94621 --- Comment #6 from Richard Biener --- (In reply to Ola Olsson from comment #5) > My god. Insanely fast. Dobra robota/prace! The power of Free Software / Open Source.
[Bug tree-optimization/94621] [9/10 Regression] GCC 9.2.1 segfaults when compiling file with -O3 since r9-5354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94621 --- Comment #7 from Richard Biener --- (In reply to Jakub Jelinek from comment #4) > Created attachment 48294 [details] > gcc10-pr94621.patch > > Untested fix. LGTM (obvious even)
[Bug fortran/94578] Incorrect assignment of RESHAPE() result to a Fortran pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578 --- Comment #7 from Jan-Willem Blokland --- Thanks for verifying my case. Your test makes me wonder which intrinsics are effected in this and other versions of gfortran. Furthermore, I assume it also happens when you pass the pointer to subroutine or function (see example below). This would be more difficult to debug. Fortunately, for my case the pointer assignment and the usage of the intrinsic where in the same function/subroutine. program main implicit none type foo integer :: x, y end type foo integer :: i integer, dimension (2,2) :: array2d integer, dimension(:), pointer :: array1d type(foo), dimension(2*2), target :: solution data array2d /1,3,2,4/ array1d => solution%x array1d = reshape (source=array2d, shape=shape(array1d)) print *,maxval(array2d) call printMaxval(array1d) end program main subroutine printMaxval(array1d) implicit none integer, dimension(:), intent(in) :: array1d print*,maxval(array1d) end subroutine
[Bug c++/94314] [10 Regression] Optimizing mismatched new/delete pairs since r10-2106-g6343b6bf3bb83c87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94314 --- Comment #15 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:61b58e7fa5aea3ef0c7db2d9f75d17d65dff56a3 commit r10-7766-g61b58e7fa5aea3ef0c7db2d9f75d17d65dff56a3 Author: Jakub Jelinek Date: Fri Apr 17 09:01:08 2020 +0200 testsuite: Fix up test language requirements [PR94314] With c++11 one gets: Excess errors: .../testsuite/g++.dg/pr94314-4.C:19:28: error: too many arguments to function 'void operator delete(void*)' because C++ sized deallocation is a C++14 feature. 2020-04-17 Jakub Jelinek PR c++/94314 * g++.dg/pr94314-4.C: Require c++14 rather than c++11.
[Bug c++/94628] [8/9/10 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94628 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.5
[Bug libstdc++/94627] [9/10 Regression] std::match_results equality comparisons should not be noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94627 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/94630] General bug for changes needed to switch the PowerPC long double default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94630 Richard Biener changed: What|Removed |Added Version|unknown |10.0 Keywords||ABI --- Comment #4 from Richard Biener --- Not sure if it is a good idea to change the ABI. Educate people to use _Float* types?
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #1 from Richard Biener --- Picking those obvious to me at the moment.
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #2 from Richard Biener --- Created attachment 48298 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48298&action=edit parts I am testing
[Bug gcov-profile/94570] -fprofile-dir is broken on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94570 --- Comment #12 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:e9f799d25973fc38022c5ea71ed5a2bca58a847f commit r10-7767-ge9f799d25973fc38022c5ea71ed5a2bca58a847f Author: Martin Liska Date: Fri Apr 17 09:22:51 2020 +0200 Do not use HAVE_DOS_BASED_FILE_SYSTEM for Cygwin. PR gcov-profile/94570 * ltmain.sh: Do not define HAVE_DOS_BASED_FILE_SYSTEM for CYGWIN. PR gcov-profile/94570 * coverage.c (coverage_init): Use separator properly. PR gcov-profile/94570 * filenames.h (defined): Do not define HAVE_DOS_BASED_FILE_SYSTEM for CYGWIN. Co-Authored-By: Jonathan Yong <10wa...@gmail.com>
[Bug tree-optimization/94621] [9/10 Regression] GCC 9.2.1 segfaults when compiling file with -O3 since r9-5354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94621 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c58cb6ac6891886b7aa01c440ac71a5e7cbcba97 commit r10-7768-gc58cb6ac6891886b7aa01c440ac71a5e7cbcba97 Author: Jakub Jelinek Date: Fri Apr 17 09:07:49 2020 +0200 inliner: Don't ICE on NULL TYPE_DOMAIN [PR94621] When I've added the VLA tweak for OpenMP to avoid error_mark_nodes in the IL in type, I forgot that TYPE_DOMAIN could be NULL. Furthermore, as an optimization, this patch checks the hopefully cheapest condition that is very likely false most of the time (enabled only during OpenMP handling) first. 2020-04-17 Jakub Jelinek PR tree-optimization/94621 * tree-inline.c (remap_type_1): Don't dereference NULL TYPE_DOMAIN. Move id->adjust_array_error_bounds check first in the condition. * gcc.c-torture/compile/pr94621.c: New test.
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Richard Biener --- Btw, the ipa_polymorphic_call_context::set_by_invariant looks possible wrong-code ...
[Bug gcov-profile/94570] -fprofile-dir is broken on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94570 Martin Liška changed: What|Removed |Added Known to fail||9.3.0 Known to work||10.0 --- Comment #13 from Martin Liška --- Fixed on master so far.
[Bug rtl-optimization/94618] [8/9/10 Regression] '-fcompare-debug' failure (length) with -O2 -fnon-call-exceptions since r8-565-g7581ce9a1ad6df9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94618 --- Comment #6 from Richard Biener --- (In reply to Jakub Jelinek from comment #5) > Created attachment 48293 [details] > gcc10-pr94618.patch > > Untested fix. Looks logically correct - but are there no helpers for this on the RTL side? Like LAST_NONDEBUG_INSN (BB) or so? Or skip_debug_insns_until_bb_end? Possibly this is the only such case of course ...
[Bug c/92326] [10 Regression] wrong bound in zero-length array diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92326 --- Comment #11 from Martin Liška --- All right, thanks for the clarification. Btw. qemu fixed the warning in the meantime: https://github.com/patchew-project/qemu/commit/4ce1e15fbc7266a108a7c77a3962644b3935346e
[Bug c++/94632] New: [10 Regression] canonical types differ for identical types since r10-7622-g12f55e030ed068d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94632
Bug ID: 94632
Summary: [10 Regression] canonical types differ for identical
types since r10-7622-g12f55e030ed068d5
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: ppalka at gcc dot gnu.org
Target Milestone: ---
It affects the build of libqt5-qtwebengine package:
$ cat wtf.ii
template struct a;
template struct b;
template class c {
template void d(f e, typename b::h>::g);
public:
static bool h;
};
bool h = c::h;
$ g++ wtf.ii -c
wtf.ii: In instantiation of ‘class c’:
wtf.ii:8:16: required from here
wtf.ii:4:30: internal compiler error: canonical types differ for identical
types ‘b::h>’ and ‘b::h>’
4 | template void d(f e, typename b::h>::g);
| ^
0xb29f7d comptypes(tree_node*, tree_node*, int)
/home/marxin/Programming/gcc/gcc/cp/typeck.c:1519
0xb299d4 structural_comptypes
/home/marxin/Programming/gcc/gcc/cp/typeck.c:1410
0xace7ba maybe_rebuild_function_decl_type
/home/marxin/Programming/gcc/gcc/cp/pt.c:13541
0xace7ba tsubst_function_decl
/home/marxin/Programming/gcc/gcc/cp/pt.c:13778
0xad0c90 tsubst_template_decl
/home/marxin/Programming/gcc/gcc/cp/pt.c:14018
0xab94ee tsubst_decl
/home/marxin/Programming/gcc/gcc/cp/pt.c:14140
0xac2ef7 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:15026
0xade994 instantiate_class_template_1
/home/marxin/Programming/gcc/gcc/cp/pt.c:11728
0xade994 instantiate_class_template(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.c:12036
0xb2579d complete_type(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/typeck.c:137
0xa76193 cp_parser_nested_name_specifier_opt
/home/marxin/Programming/gcc/gcc/cp/parser.c:6639
0xa7302e cp_parser_simple_type_specifier
/home/marxin/Programming/gcc/gcc/cp/parser.c:18126
0xa744e7 cp_parser_postfix_expression
/home/marxin/Programming/gcc/gcc/cp/parser.c:7173
0xa7d28f cp_parser_unary_expression
/home/marxin/Programming/gcc/gcc/cp/parser.c:8560
0xa5421f cp_parser_cast_expression
/home/marxin/Programming/gcc/gcc/cp/parser.c:9451
0xa54a59 cp_parser_binary_expression
/home/marxin/Programming/gcc/gcc/cp/parser.c:9554
0xa564de cp_parser_assignment_expression
/home/marxin/Programming/gcc/gcc/cp/parser.c:9859
0xa5548d cp_parser_constant_expression
/home/marxin/Programming/gcc/gcc/cp/parser.c:10153
0xa55a51 cp_parser_initializer_clause
/home/marxin/Programming/gcc/gcc/cp/parser.c:23216
0xa59cc7 cp_parser_initializer
/home/marxin/Programming/gcc/gcc/cp/parser.c:23154
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/94632] [10 Regression] canonical types differ for identical types since r10-7622-g12f55e030ed068d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94632 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Known to work||9.3.0 Last reconfirmed||2020-04-17 Target Milestone|--- |10.0 Known to fail||10.0 Status|UNCONFIRMED |NEW Priority|P3 |P1
[Bug rtl-optimization/94618] [8/9/10 Regression] '-fcompare-debug' failure (length) with -O2 -fnon-call-exceptions since r8-565-g7581ce9a1ad6df9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94618
--- Comment #7 from Jakub Jelinek ---
Perhaps if we checked DEBUG_INSN_P on BB_END, we could then use
prev_nondebug_insn, so like:
if (INSN_P (insn) && BLOCK_FOR_INSN (insn))
{
basic_block bb = BLOCK_FOR_INSN (insn);
if (BB_END (bb) == insn
|| (DEBUG_INSN_P (BB_END (bb))
&& prev_nondebug_insn (BB_END (bb)) == insn))
purge = true;
}
?
[Bug rtl-optimization/94618] [8/9/10 Regression] '-fcompare-debug' failure (length) with -O2 -fnon-call-exceptions since r8-565-g7581ce9a1ad6df9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94618 --- Comment #8 from Jakub Jelinek --- Though, a slight advantage of the patch as is is that it will do any insn walk only if two conditions are met, BB_END is a DEBUG_INSN and insn is followed by a DEBUG_INSN. My thoughs were that there could be a large bb with hundreds of DEBUG_INSNs at the end and if we e.g. started deleting insn from the start, even if they aren't really followed by any DEBUG_INSNs, we'd still walk all of them each time.
[Bug libgomp/94612] Failed to build simple examples with offloading.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94612 --- Comment #12 from Martin Liška --- Ok, I can reproduce it locally on openSUSE.
[Bug c/94631] Wrong codegen for arithmetic on bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94631 --- Comment #4 from Richard Biener --- (In reply to Andrew Pinski from comment #3) > (In reply to Rich Felker from comment #2) > > So basically the outcome of DR120 was allowing the GCC behavior? It still > > seems like a bad thing, not required, and likely to produce exploitable bugs > > (due to truncation of arithmetic) as well as very poor-performance code (due > > to constant masking). > > Note this only matters when the size of the bit-field is less than the size > of int. bigger than the size of int (due to default integer promotions still applying).
[Bug rtl-optimization/94618] [8/9/10 Regression] '-fcompare-debug' failure (length) with -O2 -fnon-call-exceptions since r8-565-g7581ce9a1ad6df9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94618 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c41884a09206be0e21cad7eea71b9754daa969d4 commit r10-7769-gc41884a09206be0e21cad7eea71b9754daa969d4 Author: Jakub Jelinek Date: Fri Apr 17 10:33:27 2020 +0200 Fix -fcompare-debug issue in delete_insn_and_edges [PR94618] delete_insn_and_edges calls purge_dead_edges whenever deleting the last insn in a bb, whatever it is. If it called it only for mandatory last insns in the basic block (that may not be followed by DEBUG_INSNs, dunno if that is control_flow_insn_p or something more complex), that wouldn't be a problem, but as it calls it on any last insn and can actually do something in the bb, if such an insn is followed by one more more DEBUG_INSNs and nothing else in the same bb, we don't call purge_dead_edges with -g and do call it with -g0. On the testcase, there are two reg-to-reg moves with REG_EH_REGION notes (previously memory accesses but simplified and yet not optimized), and the second is followed by DEBUG_INSNs; the second move is delete_insn_and_edges and after removing it, for -g0 purge_dead_edges removes the REG_EH_REGION from the now last insn in the bb (the first reg-to-reg move), while for -g it isn't called and things diverge from that quickly on. Fixed by calling purdge_dead_edges even if we remove the last real insn followed only by DEBUG_INSNs in the same bb. 2020-04-17 Jakub Jelinek PR rtl-optimization/94618 * cfgrtl.c (delete_insn_and_edges): Set purge not just when insn is the BB_END of its block, but also when it is only followed by DEBUG_INSNs in its block. * g++.dg/opt/pr94618.C: New test.
[Bug tree-optimization/94621] [9 Regression] GCC 9.2.1 segfaults when compiling file with -O3 since r9-5354
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94621 Jakub Jelinek changed: What|Removed |Added Summary|[9/10 Regression] GCC 9.2.1 |[9 Regression] GCC 9.2.1 |segfaults when compiling|segfaults when compiling |file with -O3 since r9-5354 |file with -O3 since r9-5354 --- Comment #9 from Jakub Jelinek --- Fixed on the trunk so far, queued for backporting to 9.
[Bug rtl-optimization/94618] [8/9 Regression] '-fcompare-debug' failure (length) with -O2 -fnon-call-exceptions since r8-565-g7581ce9a1ad6df9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94618 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] |[8/9 Regression] |'-fcompare-debug' failure |'-fcompare-debug' failure |(length) with -O2 |(length) with -O2 |-fnon-call-exceptions since |-fnon-call-exceptions since |r8-565-g7581ce9a1ad6df9c|r8-565-g7581ce9a1ad6df9c --- Comment #10 from Jakub Jelinek --- Fixed on the trunk (so far).
[Bug libgomp/94612] Failed to build simple examples with offloading.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94612 --- Comment #13 from Martin Liška --- I've got a patch for it.
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a64468a3034dd8e2d0794a5be84b8da544ffe2c3 commit r10-7770-ga64468a3034dd8e2d0794a5be84b8da544ffe2c3 Author: Richard Biener Date: Fri Apr 17 09:19:32 2020 +0200 fix PVS studio reported bugs 2020-04-17 Richard Biener PR other/94629 * cgraphclones.c (cgraph_node::create_clone): Remove duplicate initialization. * dwarf2out.c (dw_val_equal_p): Fix pasto in dw_val_class_vms_delta comparison. * optabs.c (expand_binop_directly): Fix pasto in commutation check. * tree-ssa-sccvn.c (vn_reference_lookup_pieces): Fix pasto in initialization.
[Bug fortran/94129] Using almost any openacc !$acc directive causes ICE "compressed stream: data error"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94129 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 94612 ***
[Bug lto/94612] Failed to build simple examples with offloading.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94612 Martin Liška changed: What|Removed |Added CC||andrew at blamsoft dot com --- Comment #14 from Martin Liška --- *** Bug 94129 has been marked as a duplicate of this bug. ***
[Bug lto/94612] [10 Regression] Failed to build simple examples with offloading.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94612 Martin Liška changed: What|Removed |Added Summary|Failed to build simple |[10 Regression] Failed to |examples with offloading. |build simple examples with ||offloading. Priority|P3 |P1
[Bug go/94633] New: golang 1.14.2 fails to bootstrap using GCC 10 on riscv64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94633 Bug ID: 94633 Summary: golang 1.14.2 fails to bootstrap using GCC 10 on riscv64-linux-gnu Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: doko at debian dot org CC: cmang at google dot com Target Milestone: --- tried to bootstrap golang-1.14.2 using GCC trunk, which succeeds on x86_64-linux-gnu, but fails on riscv64-linux-gnu. The stage1 compile seems to be stuck, and times out on buildds.
[Bug tree-optimization/94043] [9 Regression] ICE in superloop_at_depth, at cfgloop.c:78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043 --- Comment #23 from CVS Commits --- The releases/gcc-9 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:a809efd70d18c079d41051dc408de5e5f86a9797 commit r9-8506-ga809efd70d18c079d41051dc408de5e5f86a9797 Author: Kewen Lin Date: Tue Mar 31 22:48:46 2020 -0500 Fix PR94043 by making vect_live_op generate lc-phi As PR94043 shows, my commit r10-4524 exposed one issue in vectorizable_live_operation, which inserts one extra BB before the single exit, leading unexpected operand expansion and unexpected loop depth assertion. As Richi suggested, this patch is to teach vectorizable_live_operation to generate loop closed phi for vec_lhs, it looks like: loop; # lhs' = PHI => loop; # vec_lhs' = PHI new_tree = BIT_FIELD_REF ; lhs' = new_tree; I noticed that there are some SLP cases that have same lhs and vec_lhs but different offsets, which can make us have more PHIs for the same vec_lhs there. But I think it would be fine since only one of them is actually live, the others should be eliminated by the following dce. So the patch doesn't check whether there is one phi for vec_lhs, just create one directly instead. Bootstrapped/regtested on powerpc64le-linux-gnu (LE) P8. Backport from mainline. 2020-04-01 Kewen Lin gcc/ChangeLog PR tree-optimization/94043 * tree-vect-loop.c (vectorizable_live_operation): Generate loop-closed phi for vec_lhs and use it for lane extraction. gcc/testsuite/ChangeLog PR tree-optimization/94043 * gfortran.dg/graphite/vect-pr94043.f90: New test.
[Bug tree-optimization/94443] [10 Regression] 510.parest_r and 526.blender_r ICE: verify_ssa failed since r10-7491-gbd0f22a8d5caea8905f38ff1fafce31c1b7d33ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94443 --- Comment #20 from CVS Commits --- The releases/gcc-9 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:7bce1c72444bb3c9636b492975a0494b376678cf commit r9-8507-g7bce1c72444bb3c9636b492975a0494b376678cf Author: Kewen Lin Date: Fri Apr 3 02:10:08 2020 -0500 Fix PR94443 with gsi_insert_seq_before [PR94443] This patch is to fix the stupid mistake by using gsi_insert_seq_before instead of gsi_insert_before. BTW, the regression testing on one x86_64 machine from CFarm is unable to reveal it (I guess due to native arch sandybridge?), so I specified additional option -march=znver2 and verified the coverage. Bootstrapped/regtested on powerpc64le-linux-gnu (P9) and x86_64-pc-linux-gnu, also verified the fail cases in related PRs. Backport from mainline. 2020-04-03 Kewen Lin gcc/ PR tree-optimization/94443 * tree-vect-loop.c (vectorizable_live_operation): Use gsi_insert_seq_before to replace gsi_insert_before. gcc/testsuite/ PR tree-optimization/94443 * gcc.dg/vect/pr94443.c: New test.
[Bug lto/94612] [10 Regression] Failed to build simple examples with offloading.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94612 --- Comment #15 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:b835645c7a51b7e99092abe61d677aa491836f95 commit r10-7771-gb835645c7a51b7e99092abe61d677aa491836f95 Author: Martin Liska Date: Fri Apr 17 10:57:03 2020 +0200 Initialize file_data->lto_section_header before lto_mode_identity_table call. PR lto/94612 * lto-common.c: Initialize file_data->lto_section_header before lto_mode_identity_table call. It is needed because it decompresses a LTO section.
[Bug lto/94612] [10 Regression] Failed to build simple examples with offloading.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94612 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Martin Liška --- Fixed.
[Bug tree-optimization/94043] [9 Regression] ICE in superloop_at_depth, at cfgloop.c:78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94043 Kewen Lin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #24 from Kewen Lin --- Backported via r9-8506 and its related r9-8507.
[Bug go/94633] golang 1.14.2 fails to bootstrap using GCC 10 on riscv64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94633 --- Comment #1 from Andreas Schwab --- Try -fno-variable-tracking.
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- We should for GCC11 discuss if we want to implement some of these checks, either in -fanalyzer, or as normal GCC warnings. E.g. the foo = something; // code that can't affect foo foo = somethingelse; is perhaps something that should be warned as early as possible after getting into GIMPLE, before inlining because it is quite common that inlines overwrite something, and in the FEs it is likely too early.
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Eric Gallager changed: What|Removed |Added Summary|[meta-bug] Issues that |[meta-bug] Issues in gcc |static analyzers (cppcheck, |that other static analyzers |clang-static-analyzer) find |(cppcheck, |that gcc misses |clang-static-analyzer, ||PVS-studio) find that gcc ||misses --- Comment #8 from Eric Gallager --- updating title to include PVS studio bugs
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 --- Comment #9 from Eric Gallager --- (In reply to Eric Gallager from comment #8) > updating title to include PVS studio bugs actually it looks like there was already a previous meta-bug for PVS-Studio, bug 77421, but it's closed already... do we want to reopen that one, or use this one for PVS-Studio bugs as well?
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #6 from David Binderman --- (In reply to Jakub Jelinek from comment #5) > We should for GCC11 discuss if we want to implement some of these checks, > either in -fanalyzer, or as normal GCC warnings. > E.g. the > foo = something; > // code that can't affect foo > foo = somethingelse; > is perhaps something that should be warned as early as possible after > getting into GIMPLE, before inlining because it is quite common that inlines > overwrite something, and in the FEs it is likely too early. A quick look at recent cppcheck output over the gcc trunk source code suggests that there are 162 cases of redundant assignment like this. Some of them might well be false positives.
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #7 from Jakub Jelinek --- (In reply to David Binderman from comment #6) > (In reply to Jakub Jelinek from comment #5) > > We should for GCC11 discuss if we want to implement some of these checks, > > either in -fanalyzer, or as normal GCC warnings. > > E.g. the > > foo = something; > > // code that can't affect foo > > foo = somethingelse; > > is perhaps something that should be warned as early as possible after > > getting into GIMPLE, before inlining because it is quite common that inlines > > overwrite something, and in the FEs it is likely too early. > > A quick look at recent cppcheck output over the gcc trunk source code > suggests that there are 162 cases of redundant assignment like this. > > Some of them might well be false positives. Can you attach a list? I can seed through them.
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #8 from David Binderman --- Created attachment 48299 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48299&action=edit sorted list of redundant assignments
[Bug target/94538] [10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94538 --- Comment #16 from Wilco --- (In reply to Christophe Lyon from comment #15) > (In reply to Wilco from comment #14) > > (In reply to Christophe Lyon from comment #11) > > > (In reply to Wilco from comment #10) > > > > > Right, but the code is functional. > > > > It doesn't avoid the literal load from flash which is exactly what pure-code > > and slow-flash-data is all about. > > For f1 on M0, I can see: > .section.rodata.cst4,"aM",%progbits,4 > .align 2 > .LC0: > .word .LANCHOR0 > .section .text,"0x2006",%progbits > [...] > f1: > movsr3, #:upper8_15:#.LC0 > lslsr3, #8 > addsr3, #:upper0_7:#.LC0 > lslsr3, #8 > addsr3, #:lower8_15:#.LC0 > lslsr3, #8 > addsr3, #:lower0_7:#.LC0 > ldr r3, [r3]@ 6 [c=10 l=2] *thumb1_movsi_insn/8 > ldr r0, [r3]@ 7 [c=10 l=2] *thumb1_movsi_insn/8 > bx lr > [...] > .bss > .align 2 > .set.LANCHOR0,. + 0 > .type x, %object > .size x, 4 > x: > .space 4 > > So the 1st load is from .rodata.cst4 and the 2nd load is from bss, both of > which do not have the purecode bit set (unlike .text). Isn't that OK? No, it will create a lot of complaints and support queries due to the obvious regressions. It goes against the definition of pure-code and slow-flash-data which is to remove the literal loads. And given the sequence is already inefficient, we should do everything to remove the indirection which increases the codesize overhead by 75%... Another aspect that needs to be checked is that GCC correctly spills addresses and complex constants instead of rematerializing them. This is basic minimal quality that one expects for a feature like this.
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629
--- Comment #9 from Jakub Jelinek ---
Comment on attachment 48299
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48299
sorted list of redundant assignments
/* If there were any declarations or structure tags in that level,
or if this level is a function body,
create a BLOCK to record them for the life of this function. */
block = NULL_TREE;
/* Avoid function body block if possible. */
if (functionbody && subblocks && BLOCK_CHAIN (subblocks) == NULL_TREE)
keep = 0;
else if (keep == 1 || functionbody)
block = make_node (BLOCK);
if (block != NULL_TREE)
{
BLOCK_VARS (block) = decls;
BLOCK_SUBBLOCKS (block) = subblocks;
}
/* In each subblock, record that this is its superior. */
if (keep >= 0)
for (link = subblocks; link; link = BLOCK_CHAIN (link))
BLOCK_SUPERCONTEXT (link) = block;
certainly doesn't look like redundant assignment, yes, the block = NULL_TREE
could be moved into the if, but that is just programming style.
I must say I don't understand why the separate if (block != NULL_TREE) is in
there, perhaps from historic reasons there might have been more cases.
Now it would make much more sense to just do
else if (keep == 1 || functionbody)
{
block = make_node (BLOCK);
BLOCK_VARS (block) = decls;
BLOCK_SUBBLOCKS (block) = subblocks;
}
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629
Jakub Jelinek changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek ---
I have a few unimportant tweaks for this in my tree.
Anyway, e.g. in the GCN plugin, I wonder if we don't need:
diff --git a/libgomp/plugin/plugin-gcn.c b/libgomp/plugin/plugin-gcn.c
index dc72c90962c..c733b8bfb18 100644
--- a/libgomp/plugin/plugin-gcn.c
+++ b/libgomp/plugin/plugin-gcn.c
@@ -1508,7 +1508,8 @@ init_hsa_context (void)
= GOMP_PLUGIN_malloc_cleared (hsa_context.agent_count
* sizeof (struct agent_info));
status = hsa_fns.hsa_iterate_agents_fn (assign_agent_ids, &agent_index);
- if (agent_index != hsa_context.agent_count)
+ if (status != HSA_STATUS_SUCCESS
+ || agent_index != hsa_context.agent_count)
{
GOMP_PLUGIN_error ("Failed to assign IDs to all GCN agents");
return false;
@@ -3473,7 +3474,8 @@ GOMP_OFFLOAD_init_device (int n)
status = hsa_fns.hsa_agent_iterate_regions_fn (agent->id,
get_kernarg_memory_region,
&agent->kernarg_region);
- if (agent->kernarg_region.handle == (uint64_t) -1)
+ if (status != HSA_STATUS_SUCCESS
+ || agent->kernarg_region.handle == (uint64_t) -1)
{
GOMP_PLUGIN_error ("Could not find suitable memory region for kernel "
"arguments");
@@ -3486,7 +3488,8 @@ GOMP_OFFLOAD_init_device (int n)
status = hsa_fns.hsa_agent_iterate_regions_fn (agent->id,
get_data_memory_region,
&agent->data_region);
- if (agent->data_region.handle == (uint64_t) -1)
+ if (status != HSA_STATUS_SUCCESS
+ || agent->data_region.handle == (uint64_t) -1)
{
GOMP_PLUGIN_error ("Could not find suitable memory region for device "
"data");
or if instead we should drop the "status = " for the cases where nothing checks
it. Andrew?
[Bug c++/94634] New: ++(fun(a)) is acts as lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94634 Bug ID: 94634 Summary: ++(fun(a)) is acts as lvalue Product: gcc Version: 7.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ravivasani75 at gmail dot com Target Milestone: --- Created attachment 48300 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48300&action=edit ++(fun(a)) is acts as lvalue
[Bug libgomp/94635] New: [OpenMP][Offloading] mapping with alloc/delete followed by map(from/fromto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94635 Bug ID: 94635 Summary: [OpenMP][Offloading] mapping with alloc/delete followed by map(from/fromto fails Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openmp, wrong-code Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Based on an OpenMP test case from SOLLVE_VV, https://github.com/SOLLVE/sollve_vv/ Namely, based on tests/4.5/target_enter_exit_data/ test_target_enter_exit_data_allocate_array_alloc_delete.F90 The following test case works if one comments: !$omp target enter data map(alloc: my1DPtr(:)) !$omp target exit data map(delete: my1DPtr(:)) Then it prints the expected 42 … 10 … 10 … 20 … If one comments only the "map(delete:…)", it prints 42 … 10 … 0 … (should be: 10) 10 … (should be: 20) And with alloc/delete enabled, it prints: 42 … 10 … 20 20 … 31911936 17 31907872 17 31907952 (should be: 10) 10 … (should be: 20) In the 'target': when using "my1DArr = 99", the garbage values are replaced by 99, i.e. 20 20 … 99 99 … (twelf times 20 followed by eight times 99). The testsuite first tests whether alloc/delete works – which does; only re-using the alloc/delete space fails. Test case: -- implicit none INTEGER, PARAMETER :: N = 20 INTEGER, ALLOCATABLE, DIMENSION(:) :: my1DPtr INTEGER, DIMENSION(N) :: my1DArr allocate(my1DPtr(N)) !$omp target enter data map(alloc: my1DPtr(:)) !$omp target exit data map(delete: my1DPtr(:)) my1DPtr(:) = 10 my1DArr = 42 print *, my1DArr ! = 42, okay print *, my1DPtr ! = 10, okay !$omp target map(from: my1DArr) map(tofrom: my1DPtr(:)) my1DArr = my1DPtr my1DPtr(:) = 20 !$omp end target print *, my1DArr ! should be: 10 (not 0 or 20+garbage) print *, my1DPtr ! should be: 20 (and not 10) END
[Bug gcov-profile/94636] New: gcov should and could output overall coverage. This is just a 2 code lines change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94636 Bug ID: 94636 Summary: gcov should and could output overall coverage. This is just a 2 code lines change. Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: easyhack Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: okannen at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 48301 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48301&action=edit Patch to output overall coverage Gcov could output the computed overall code coverage when processing multiple file. This overall coverage is often all what is needed in CI reports. It think this is just a 2 lines change. diff --git a/gcc/gcov.c b/gcc/gcov.c index a291bac3e9e..c16895e640a 100644 --- a/gcc/gcov.c +++ b/gcc/gcov.c @@ -1510,7 +1510,8 @@ generate_results (const char *file_name) } } - if (!file_name) +if (file_name) + fnotice(stdout,"Overall:\n"); executed_summary (total_lines, total_executed); }
[Bug libgomp/94635] [OpenMP][Offloading] mapping with alloc/delete followed by map(from/tofrom:) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94635 --- Comment #1 from Tobias Burnus --- Just showing the dump – without further analysis: #pragma omp target enter data map(alloc:MEM[(c_char *)_9] [len: _8]) // _9 = my1dptr.data, _8 = 20*4 map(to:my1dptr [pointer set, len: 64]) map(alloc:my1dptr.data [pointer assign, bias: 0]) #pragma omp target exit data map(delete:MEM[(c_char *)_14] [len: _13]) // #pragma omp target num_teams(1) thread_limit(0) map(from:my1darr [len: 80]) map(tofrom:MEM[(c_char *)_21] [len: _20]) // _21 = my1dptr.data, _20 = 20*4 map(to:my1dptr [pointer set, len: 64]) map(alloc:my1dptr.data [pointer assign, bias: 0]) [child fn: MAIN__._omp_fn.0 (.omp_data_arr.22, .omp_data_sizes.23, .omp_data_kinds.24)]
[Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79469 --- Comment #2 from felix --- I realised recently that this is already expressible: #define __builtin_assume(expr) \ (__builtin_pure_p(expr) \ ? ((expr) \ ? (void) 0 \ : __builtin_unreachable()) \ : (void) 0 /* XXX: warn about side effects */) where __builtin_pure_p has the same definition that I gave under PR 6906: #define __builtin_pure_p(expr) \ (__builtin_object_size(((void) (expr), ""), 2)) As for the corner case I gave earlier, GCC manages to optimise the is_pow2 loop away at -O2 and -O3 (though not entirely at -O1), and it apparently considers statement-expressions that contain more than one statement, or any kind of loop, to have side effects. One can always check __OPTIMIZE__ to prevent spurious code from being generated at -O0. So this solution apparently performs no worse :)
[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #17 from Martin Jambor --- Created attachment 48302 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48302&action=edit Untested fix I'm playing with this - only very mildly tested - fix.
[Bug c++/94634] ++(fun(a)) is acts as lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94634 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener --- unary ++ result is an lvalue.
[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #18 from Jakub Jelinek ---
Comment on attachment 48302
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48302
Untested fix
+ /* IPA-SRA does not analyze other types of statements. */
+ gcc_unreachable ();
Won't this ICE on any is_gimple_debug stmt? Those should be just ignored and
normal SSA_NAME handling should DTRT for those.
As for PHIs, can you just gsi_remove them?
Plus, I think in isra_track_scalar_value_uses for non-is_gimple_{debug,call} we
should punt if !flag_tree_dce, i.e. when user asked not to perform dead code
elimination. Though, guess that hunk should be added only after this is tested
(and perhaps the testcase or its copy should use -fdisable-tree-dce or whatever
other way to avoid doing DCE even when flag_tree_dce is non-zero.
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #11 from Andrew Stubbs --- (In reply to Jakub Jelinek from comment #10) > or if instead we should drop the "status = " for the cases where nothing > checks it. Andrew? I think checking the status is probably good practice, even though I don't think there's an actual bug here.
[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #19 from Richard Biener --- (In reply to Martin Jambor from comment #17) > Created attachment 48302 [details] > Untested fix > > I'm playing with this - only very mildly tested - fix. Ugh. I was thinking of altering the parameter setup for cloning/inlining so that it maps a removed parameter [SSA_NAME] not to a new uninitialized variable/default-def but to error_mark_node and then either scanning the function for those, propagating & DCEing on the fly, or, during cloning/inlining seed a worklist whenever we map something to error_mark_node. The advantage is that we're leaving the IL in a clearly invalid state in case one of those slips through and that the call case you handle should handle itself by followup IPA transforms. Another option is to track a set of removed SSA names in the original and whenever we encounter an original stmt using that during the copying operation elide the copy or transform it. IIRC there's already a stmt transform hook for IPA that could eventually be used for this approach\ (the modify_gimple_stmt hook), but it alreayd gets the copied stmts so all defs have been cloned and the safety the error_mark_node approach would bring is lost.
[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #20 from Jakub Jelinek --- Looking at tree-ssa-dce.c, it uses remove_phi_node rather than gsi_remove for PHIs. And for non-PHIs, it calls release_defs after gsi_remove.
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #12 from Jakub Jelinek --- (In reply to Andrew Stubbs from comment #11) > (In reply to Jakub Jelinek from comment #10) > > or if instead we should drop the "status = " for the cases where nothing > > checks it. Andrew? > > I think checking the status is probably good practice, even though I don't > think there's an actual bug here. I have no way to test it, so if you want and can test it (perhaps with other changes), please take it over, or we throw it away, we don't have to fix all the warnings, we just should skim through it to find if there aren't any actual bugs.
[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #21 from rguenther at suse dot de --- On Fri, 17 Apr 2020, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 > > --- Comment #20 from Jakub Jelinek --- > Looking at tree-ssa-dce.c, it uses remove_phi_node rather than gsi_remove for > PHIs. And for non-PHIs, it calls release_defs after gsi_remove. Btw, I'd much prefer to not first copy the stmts and then remove them. Instead the DCE "analysis" can be done on the original IL and stmts be "marked" to be elided during copying. That saves generating SSA names and gimple stmts rather than needing to remove them after the fact.
[Bug c++/94632] [10 Regression] canonical types differ for identical types since r10-7622-g12f55e030ed068d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94632 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #1 from Patrick Palka --- Looking into it.
[Bug target/94630] General bug for changes needed to switch the PowerPC long double default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94630 --- Comment #5 from Michael Meissner --- Note, at the moment, the patches are to make the existing configure switch (--with-long-double=ieee) work correctly. However, we need all of the pieces in place (gcc, glibc, libstdc++, etc.) before we can contemplate changing the ABI.
[Bug objc/94637] New: @selector() broken for selectors containing repeated colons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94637
Bug ID: 94637
Summary: @selector() broken for selectors containing repeated
colons
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
Assignee: unassigned at gcc dot gnu.org
Reporter: rfm at gnu dot org
Target Milestone: ---
The compiler fails to compile legal Objective-C programs which use the
@selector() syntax to send message to objects, if those messages have multiple
parameters and the method does not describe each one.
eg. when given @selector(styleoffsets::) the compiler errors with the
message
error: expected ‘)’ before ‘::’ token
Within @selector() each colon marks the position at which an argument would be
inserted in a method invocation (when a message is sent to an object). It is
therefore not legal for the compiler to consider a pair of colons to be a token
in this context.
In the above example, the method declaration looks like this:
- (void) styleoffsets: (float*)l : (float*)r : (float*)t : (float*)b
: (unsigned int)style;
While imo it would be better coding style to describe parameters as part of the
method name, it's certainly correct/legal objective-c to have multiple
parameters each preceded only by a colon.
A trivial program to demonstrate the bug would be
#include
#include
int main()
{
SEL s = @selector(example::);
printf("%s\n", sel_getName(s));
return 0;
}
This program, if built with the command 'gcc program.m -lobjc' should produce
an a.out which just prints the selector name.
[Bug objc/94638] New: @selector() broken for selectors containing repeated colons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94638
Bug ID: 94638
Summary: @selector() broken for selectors containing repeated
colons
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
Assignee: unassigned at gcc dot gnu.org
Reporter: rfm at gnu dot org
Target Milestone: ---
The compiler fails to compile legal Objective-C programs which use the
@selector() syntax to send message to objects, if those messages have multiple
parameters and the method does not describe each one.
eg. when given @selector(styleoffsets::) the compiler errors with the
message
error: expected ‘)’ before ‘::’ token
Within @selector() each colon marks the position at which an argument would be
inserted in a method invocation (when a message is sent to an object). It is
therefore not legal for the compiler to consider a pair of colons to be a token
in this context.
In the above example, the method declaration looks like this:
- (void) styleoffsets: (float*)l : (float*)r : (float*)t : (float*)b
: (unsigned int)style;
While imo it would be better coding style to describe parameters as part of the
method name, it's certainly correct/legal objective-c to have multiple
parameters each preceded only by a colon.
A trivial program to demonstrate the bug would be
#include
#include
int main()
{
SEL s = @selector(example::);
printf("%s\n", sel_getName(s));
return 0;
}
This program, if built with the command 'gcc program.m -lobjc' should produce
an a.out which just prints the selector name.
[Bug objc/94638] @selector() broken for selectors containing repeated colons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94638 rfm at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from rfm at gnu dot org --- Resolving as duplicate since I accidentally submitted the same report twice *** This bug has been marked as a duplicate of bug 94637 ***
[Bug objc/94637] @selector() broken for selectors containing repeated colons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94637 --- Comment #1 from rfm at gnu dot org --- *** Bug 94638 has been marked as a duplicate of this bug. ***
[Bug c++/94597] [10 Regression] ICE while using a concept checking for user defined conversion operator since r10-3735-gcb57504a55015891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94597 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P3 |P1
[Bug c++/94549] [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94549 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-04-17 Priority|P3 |P1 --- Comment #1 from Jakub Jelinek --- Rejected since r10-3735-gcb57504a550158913258e5be8ddb991376475efb
[Bug c++/94608] Fix for PR94426 causes a regression in g++.dg/lto/pr83720 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94608 --- Comment #2 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:256f2b632908ba46bb185c4850fc8e79dfdb9dbc commit r10-7772-g256f2b632908ba46bb185c4850fc8e79dfdb9dbc Author: Nathan Sidwell Date: Fri Apr 17 06:07:33 2020 -0700 Avoid testcase warning on arm ABI [pr94608] PR c++/94608 * g++.dg/lto/pr83720_0.C: Add fn def to avoid warning on arm ABI.
[Bug c++/94608] Fix for PR94426 causes a regression in g++.dg/lto/pr83720 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94608 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Nathan Sidwell --- Fixed 75fbe1b98c7
[Bug analyzer/94639] New: false-positive uninitialized value on fixed sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94639
Bug ID: 94639
Summary: false-positive uninitialized value on fixed sized
array
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: cgzones at googlemail dot com
Target Milestone: ---
Minimized code snippet:
```
#include
void validatedatetime(const char *str)
{
const char *templates[] = {"-dd-dd dd:dd", "-dd-dd"};
size_t len = strlen(str);
for (unsigned t = 0; t < 2; t++) {
if (len != strlen(templates[t])) {
continue;
}
}
}
```
Original code:
https://github.com/vergoh/vnstat/blob/f98c27eaba27ebda703737f8a5539a77b891561e/src/misc.c#L357
GCC analyzer output:
```
$ gcc-10 -c -Wall -Wextra -fanalyzer fixed-array.c
fixed-array.c: In function ‘validatedatetime’:
fixed-array.c:10:28: warning: use of uninitialized value ‘’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
10 | if (len != strlen(templates[t])) {
|^~~~
‘validatedatetime’: events 1-7
|
|9 | for (unsigned t = 0; t < 2; t++) {
| | ^~~ ~~~
| | ||
| | |(4) ...to here
| | (1) following ‘true’ branch (when ‘t <= 1’)...
| | (5) following ‘true’ branch (when ‘t <= 1’)...
| 10 | if (len != strlen(templates[t])) {
| |~
| || |
| || (2) ...to here
| || (6) ...to here
| || (7) use of uninitialized value
‘’ here
| |(3) following ‘false’ branch...
|
```
GCC version:
```
gcc-10 (Debian 10-20200411-1) 10.0.1 20200411 (experimental) [master revision
bb87d5cc77d:75961caccb7:f883c46b4877f637e0fa5025b4d6b5c9040ec566]
```
[Bug c++/94632] [10 Regression] canonical types differ for identical types since r10-7622-g12f55e030ed068d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94632
--- Comment #2 from Patrick Palka ---
Smaller testcase that exhibits the ICE:
template struct b;
template class c {
template static void d(f e, b x);
public:
static const bool h = false;
};
bool y = c::h;
[Bug analyzer/94640] New: false-positive leaking FILE pointer assigned to function passed pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94640
Bug ID: 94640
Summary: false-positive leaking FILE pointer assigned to
function passed pointer
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: cgzones at googlemail dot com
Target Milestone: ---
Minimized code snippet:
```
#include
int debug;
int opencfgfile(const char *cfgfile, FILE **fd)
{
if (cfgfile[0] != '\0') {
if ((*fd = fopen(cfgfile, "r")) != NULL) {
if (debug) // <-- this seems to trigger the fp
printf("Config file: --config\n");
}
}
return 2;
}
```
Original code:
https://github.com/vergoh/vnstat/blob/f98c27eaba27ebda703737f8a5539a77b891561e/src/cfg.c#L364
GCC analyzer output:
```
$ gcc-10 -c -Wall -Wextra -fanalyzer return_filepointer.c
return_filepointer.c: In function ‘opencfgfile’:
return_filepointer.c:10:8: warning: leak of FILE ‘’ [CWE-775]
[-Wanalyzer-file-leak]
10 |if (debug)
|^
‘opencfgfile’: events 1-7
|
|7 | if (cfgfile[0] != '\0') {
| |^
| ||
| |(1) following ‘true’ branch...
|8 |
|9 | if ((*fd = fopen(cfgfile, "r")) != NULL) {
| |~ ~~~
| || |
| || (2) ...to here
| || (3) opened here
| |(4) assuming ‘’ is non-NULL
| |(5) following ‘true’ branch...
| 10 |if (debug)
| |~
| ||
| |(6) ...to here
| |(7) ‘’ leaks here; was opened at (3)
|
```
GCC version:
```
gcc-10 (Debian 10-20200411-1) 10.0.1 20200411 (experimental) [master revision
bb87d5cc77d:75961caccb7:f883c46b4877f637e0fa5025b4d6b5c9040ec566]
```
[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #22 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #18)
> Comment on attachment 48302 [details]
> Untested fix
>
> + /* IPA-SRA does not analyze other types of statements. */
> + gcc_unreachable ();
> Won't this ICE on any is_gimple_debug stmt? Those should be just ignored
> and normal SSA_NAME handling should DTRT for those.
Yeah, it most probably will, I wrote it was only very mildly tested
(i.e. I only ran IPA testcases on it) - I wanted to post what I had
before I had to stop working on this for a few hours.
> As for PHIs, can you just gsi_remove them?
> Looking at tree-ssa-dce.c, it uses remove_phi_node rather than
> gsi_remove for PHIs. And for non-PHIs, it calls release_defs after
> gsi_remove.
You are again most probably right, I keep forgetting about this.
>
> Plus, I think in isra_track_scalar_value_uses for non-is_gimple_{debug,call}
> we should punt if !flag_tree_dce, i.e. when user asked not to perform dead
> code elimination. Though, guess that hunk should be added only after this
> is tested (and perhaps the testcase or its copy should use
> -fdisable-tree-dce or whatever other way to avoid doing DCE even when
> flag_tree_dce is non-zero.
OK, that makes sense. I'd slightly prefer the patch in comment #11
for this so that direct passes of a parameter to another function
without any modification is still not considered as doing DCE - but I
also do not really care too much.
[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #23 from Jakub Jelinek --- Instead of #c11 I meant: - else if ((is_gimple_assign (stmt) && !gimple_has_volatile_ops (stmt)) -|| gimple_code (stmt) == GIMPLE_PHI) + else if (flag_tree_dce +&& ((is_gimple_assign (stmt) && !gimple_has_volatile_ops (stmt)) +|| gimple_code (stmt) == GIMPLE_PHI)) because the res = -1 handling is in the else after this already. For what Richi is proposing, I guess one needs to run the analysis somewhere (early tree_function_versioning or elsewhere?, note in a hash_set stmts that shouldn't be copied, add pointer to that hash_set to copy_body_data and perhaps in remap_gimple_stmt if the hash_set pointer is non-NULL, check early if stmt is in it and in that case return NULL (like we already return NULL for debug stmts if we want to drop them). Most likely the lhs of such to be removed statements need to be also added to id.killed_new_ssa_names (and verify if it works properly).
[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #25 from Martin Jambor --- (In reply to rguent...@suse.de from comment #21) > Btw, I'd much prefer to not first copy the stmts and then remove them. > Instead the DCE "analysis" can be done on the original IL and stmts > be "marked" to be elided during copying. That saves generating > SSA names and gimple stmts rather than needing to remove them after the > fact. It is of course easy to change the patch to do the analysis on the original and just create a hash_set of statements/SSA_NAMES to not copy. I'll do that. As far as remapping the removed values to ERROR_MARK, I'm not sure. We'd need to remap some SSA_NAMES of the same DECL differently than other names (e.g. default-definition of the removed PARM_DECL would get remapped to ERROR_MARK but not other SSA_NAMES and similarly for other SSA_NAMES derived from those default-defs) ...and ATM I do not know to what extent that is a problem. But I can try.
[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #24 from rguenther at suse dot de --- On April 17, 2020 3:53:07 PM GMT+02:00, "jakub at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 > >--- Comment #23 from Jakub Jelinek --- >Instead of #c11 I meant: >- else if ((is_gimple_assign (stmt) && !gimple_has_volatile_ops >(stmt)) >-|| gimple_code (stmt) == GIMPLE_PHI) >+ else if (flag_tree_dce >+&& ((is_gimple_assign (stmt) && >!gimple_has_volatile_ops >(stmt)) >+|| gimple_code (stmt) == GIMPLE_PHI)) >because the res = -1 handling is in the else after this already. > >For what Richi is proposing, I guess one needs to run the analysis >somewhere >(early tree_function_versioning or elsewhere?, note in a hash_set stmts >that >shouldn't be copied, add pointer to that hash_set to copy_body_data and >perhaps >in remap_gimple_stmt if the hash_set pointer is non-NULL, check early >if stmt >is in it and in that case return NULL (like we already return NULL for >debug >stmts if we want to drop them). >Most likely the lhs of such to be removed statements need to be also >added to >id.killed_new_ssa_names (and verify if it works properly). I'd definitely make sure to map supposed to be DCEd defs to error_mark_node. For the marking one could add id.plf_to_dce and clear/set the plf on the stmts.
[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #26 from Jakub Jelinek --- For debug stmts, it would be best if we could use those DEBUG D#Y s=> parm DEBUG var => D#Y added in if (param_body_adjs && MAY_HAVE_DEBUG_BIND_STMTS). Though, if we remove already during the copy_bb by not actually creating the stmt, I'm afraid that will mean the debug info is lost (debug stmts will be reset), unless we for the lhs of to be dced stmts manually create debug temporaries and debug stmts when we remap_gimple_stmt those stmts (for SSA_NAMEs that are directly (or indirectly!) used in debug stmts). If we do what Martin was proposing instead, i.e. copy the stmts and then DCE them afterwards, it might work properly (perhaps only if we DCE them in the right order).
[Bug objc/94637] @selector() broken for selectors containing repeated colons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94637 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||iains at gcc dot gnu.org, ||mikestump at comcast dot net --- Comment #2 from Eric Gallager --- cc-ing Objective C maintainers
[Bug fortran/94578] Incorrect assignment of RESHAPE() result to a Fortran pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578 --- Comment #8 from Thomas Koenig --- The bug appears to affect intrinsics only, for example this program main implicit none type foo integer :: x, y end type foo integer, dimension(:), pointer :: bp type (foo), dimension(4), target :: b data b%x /1,2,3,4/ data b%y /-1,-2,-3,-4/ bp => b%x bp = x() print *,bp contains function x() integer, dimension(4) :: x x = [11,12,13,14] end function x end program main works as expected (and creates an array temporary). Let's see what we can do here, if this should be solved on the library side or if we should just insert a temporary array here...
[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385 --- Comment #27 from Jakub Jelinek --- Now, perhaps the analysis code could also detect which lhs are directly or indirectly needed by debug stmts and when doing this return NULL in remap_gimple_stmt, we could do something like (much simplified) insert_debug_temp_for_var_def in there. Though unsure if we must always handle first the SSA_NAME definitions before uses, if not, then we'd need to figure out the SSA_NAME to DEBUG_EXPR_DECL mapping early and then just let remap_gimple_stmt add the debug stmt for it. Perhaps ignore debug stmts for now as long as it doesn't ICE on them and I'll try to do something for those?
[Bug target/94567] [10 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567 --- Comment #16 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:1dfc50232dcb703454db4f54c538042a32be2138 commit r10-7773-g1dfc50232dcb703454db4f54c538042a32be2138 Author: Jakub Jelinek Date: Fri Apr 17 16:56:12 2020 +0200 i386: Fix up *testqi_ext_3 define_insn_and_split [PR94567] As the testcase shows, there are unfortunately more problematic cases in *testqi_ext_3 if the mode is not CCZmode, because the sign flag might not behave the same between the insn with zero_extract and what we split it into. The previous fix to the insn condition was because *testdi_1 for mask with upper 32-bits clear and bit 31 set is implemented using SImode test and thus SF is set depending on that bit 31 rather than on always cleared. But we can have other cases. On the zero_extract (which has mode), we can have either the pos + len == precision of mode, or pos + len < precision of mode cases. The former one copies the most significant bit into SF, the latter will have SF always cleared. For the former case, either it is a zero_extract from a larger mode, but then when we perform test in that larger mode, SF will be always clear and thus mismatch from the zero_extract case (so we need to enforce CCZmode), or it will be a zero_extract from same mode with pos 0 and len equal to mode precision, such zero_extracts should have been really simplified into their first operand. For the latter case, when SF is always clear on the define_insn with zero_extract, we need to split into something that doesn't sometimes set SF, i.e. it has to be a test with mask that doesn't have the most significant bit set. In some cases it can be achieved through using test in a wider mode (e.g. in the testcase, there is (zero_extract:SI (reg:HI) (const_int 13) (const_int 3)) which will always set SF to 0, but we split it into (and:HI (reg:HI) (const_int -8)) which will copy the MSB of (reg:HI) into SF, but we can do: (and:SI (subreg:SI (reg:HI) 0) (const_int 0xfff8)) which will keep SF always cleared), but there are various cases where we can't (when already using DImode, or when SImode and we'd turned it into the problematic *testdi_1 implemented using SImode test, or when the val operand is a MEM (we don't want to read from memory more than the user originally wanted), paradoxical subreg of MEM could be problematic too if we through the narrowing end up with a MEM). So, the patch attempts to require CCZmode (and not CCNOmode) if it can't really ensure the SF will have same meaning between the define_insn and what we split it into, and if we decide we allow CCNOmode, it needs to avoid performing narrowing and/or widen if pos + len would indicate we'd have MSB set in the mask. 2020-04-17 Jakub Jelinek Jeff Law PR target/94567 * config/i386/i386.md (*testqi_ext_3): Use CCZmode rather than CCNOmode in ix86_match_ccmode if len is equal to mode precision, or pos + len >= 32, or pos + len is equal to operands[2] precision and operands[2] is not a register operand. During splitting perform SImode AND if operands[0] doesn't have CCZmode and pos + len is equal to mode precision. * gcc.c-torture/execute/pr94567.c: New test. Co-Authored-By: Jeff Law
[Bug c/92326] [10 Regression] wrong bound in zero-length array diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92326 --- Comment #12 from Martin Sebor --- Thanks! I'm glad to see the new warning has helpe identify (and fix) a real bug!
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #13 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2e3897490e0f99b22a2813cfb34d59a1ea71ff68 commit r10-7774-g2e3897490e0f99b22a2813cfb34d59a1ea71ff68 Author: Jakub Jelinek Date: Fri Apr 17 16:59:57 2020 +0200 c, c++: Fix two redundantAssignment warnings [PR94629] This change fixes two obvious redundant assignments reported by cppcheck: trunk.git/gcc/c/c-parser.c:16969:2: style: Variable 'data.clauses' is reassigned a value before the old one has been used. [redundantAssignment] trunk.git/gcc/cp/call.c:5116:9: style: Variable 'arg2' is reassigned a value before the old one has been used. [redundantAssignment] 2020-04-17 Jakub Jelinek PR other/94629 * c-parser.c (c_parser_oacc_routine): Remove redundant assignment to data.clauses. * call.c (build_conditional_expr_1): Remove redundant assignment to arg2.
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #14 from David Binderman --- There is also this one from cppcheck: trunk.git/libstdc++-v3/include/debug/formatter.h:302:40: warning: Redundant assignment of '_M_variant._M_iterator._M_constness' to itself. [selfAssignment] Source code is _M_variant._M_iterator._M_constness = _M_variant._M_iterator._M_constness = __it._S_constant() ? __const_iterator : __mutable_iterator;
[Bug target/94567] [10 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #17 from Jakub Jelinek --- Should be fixed now.
[Bug middle-end/94635] [OpenMP][Offloading] mapping with alloc/delete followed by map(from/tofrom:) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94635 Tobias Burnus changed: What|Removed |Added Ever confirmed|0 |1 Component|libgomp |middle-end Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-04-17
[Bug fortran/94578] Incorrect assignment of RESHAPE() result to a Fortran pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94578
--- Comment #9 from Thomas Koenig ---
Here's what a solution could look like. I am not really sure that this
is the way to go, there may be some corner cases (pointer to an
argument which was passed as a transposed argument?) which this
might get wrong.
diff --git a/libgfortran/generated/maxval_i4.c
b/libgfortran/generated/maxval_i4.c
index abad45b50ae..3a9ed436956 100644
--- a/libgfortran/generated/maxval_i4.c
+++ b/libgfortran/generated/maxval_i4.c
@@ -50,6 +50,7 @@ maxval_i4 (gfc_array_i4 * const restrict retarray,
index_type delta;
index_type dim;
int continue_loop;
+ int ret_factor;
/* Make dim zero based to avoid confusion. */
rank = GFC_DESCRIPTOR_RANK (array) - 1;
@@ -112,6 +113,7 @@ maxval_i4 (gfc_array_i4 * const restrict retarray,
return;
}
+ ret_factor = 1;
}
else
{
@@ -124,12 +126,16 @@ maxval_i4 (gfc_array_i4 * const restrict retarray,
if (unlikely (compile_options.bounds_check))
bounds_ifunction_return ((array_t *) retarray, extent,
"return value", "MAXVAL");
+ if (retarray->span != 0)
+ ret_factor = retarray->span / sizeof(GFC_INTEGER_4);
+ else
+ ret_factor = 1;
}
for (n = 0; n < rank; n++)
{
count[n] = 0;
- dstride[n] = GFC_DESCRIPTOR_STRIDE(retarray,n);
+ dstride[n] = GFC_DESCRIPTOR_STRIDE(retarray,n) * ret_factor;
if (extent[n] <= 0)
return;
}
[Bug gcov-profile/94636] gcov should and could output overall coverage. This is just a 2 code lines change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94636 Martin Liška changed: What|Removed |Added Keywords|easyhack| Target Milestone|--- |11.0 Last reconfirmed||2020-04-17 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Thank you for the report. The code in generate_results is bad as file_name can't be NULL. I'm testing more complex patch which will land in GCC 11 (next stage 1).
[Bug target/94630] General bug for changes needed to switch the PowerPC long double default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94630 --- Comment #6 from Segher Boessenkool --- Please mention in the TITLE that this is ONLY for the ELFv2 ABI?
[Bug driver/90983] manual documents `-Wno-stack-usage` flag, but it is unrecognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90983 --- Comment #3 from Torsten Robitzki --- Is there a workaround to disable that warning (once it was enabled) for the case, gcc detects an unbound stack usage?
[Bug driver/90392] [8/9/10 Regression] Assertion failure in ldlang.c:6868 when compiling with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90392 Jeffrey A. Law changed: What|Removed |Added Summary|[9/10 Regression] Assertion |[8/9/10 Regression] |failure in ldlang.c:6868|Assertion failure in |when compiling with -flto |ldlang.c:6868 when ||compiling with -flto CC||law at redhat dot com --- Comment #12 from Jeffrey A. Law --- GCC 8 also affected. Digging further back, but starting to wonder if the %u issue is a regression or not.
[Bug c/94631] Wrong codegen for arithmetic on bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94631
--- Comment #5 from Rich Felker ---
No, GCC's treatment also seems to mess up bitfields smaller than int and fully
governed by the standard (no implementation-defined use of non-int types):
struct foo {
unsigned x:31;
};
struct foo bar = {0};
bar.x-1 should yield UINT_MAX but yields -1 (same representation but different
type) because it behaves as a promotion from a phantom type unsigned:31 to int
rather than as having type unsigned to begin with.
This can of course be observed by comparing it against 0. It's subtle and
dangerous because it may also trigger optimization around UB of signed overflow
when the correct behavior would be well-defined modular arithmetic.
[Bug c/94626] -Wstringop-truncation warning should mention attribute((nonstring))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94626 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from Martin Sebor --- Thanks for the report (and for getting Glibc to update its headers). The problem with strncpy is that its correct and intended uses (filling a buffer without necessarily nul-terminating it) are indistinguishable from the misuses (attempting to create a possibly truncated string as a copy of another). Since there are more misuses than the correct uses of the function, the warning relies on authors of the correct code to annotate it with attribute nonstring. This is mentioned in the documentation of the warning. The warning itself doesn't mention this because the right solution is likely to fix the copy. I realize this approach makes the minority of authors of correct/safe code pay the price for the mistakes of the majority of others and so must be frustrating if you're in the first group. Sorry. The opposite approach obviously wouldn't be effective. If it helps, here's an article I wrote on this topic when the warning was first added: https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8
[Bug go/94633] golang 1.14.2 fails to bootstrap using GCC 10 on riscv64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94633 --- Comment #2 from Ian Lance Taylor --- See https://gcc.gnu.org/PR94611 and https://gcc.gnu.org/PR94466.
[Bug objc/94637] [10 Regression] @selector() broken for selectors containing repeated colons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94637 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Keywords||rejects-valid Target Milestone|--- |10.0 Status|UNCONFIRMED |NEW Last reconfirmed||2020-04-17 Summary|@selector() broken for |[10 Regression] @selector() |selectors containing|broken for selectors |repeated colons |containing repeated colons --- Comment #3 from Andrew Pinski --- Most likely caused by g:93313b94fe18f3c3de4f24f5bb3fafb4639f1c7e . That is CPP_SCOPE should be treated as two CPP_COLON tokens while parsing @selector like was done for asm parsing.
[Bug objc/94637] [10 Regression] @selector() broken for selectors containing repeated colons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94637 --- Comment #4 from Andrew Pinski --- The change needs to happen inside c_parser_objc_selector_arg.
[Bug driver/90983] manual documents `-Wno-stack-usage` flag, but it is unrecognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90983 --- Comment #4 from Martin Sebor --- Using a very large -Wstack-usage argument should effectively disable the warning. E.g., -Wstack-usage=4EiB or -Wstack-usage=$(getconf ULONG_MAX).
[Bug middle-end/94635] [OpenMP][Offloading] mapping with alloc/delete followed by map(from/tofrom:) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94635 --- Comment #2 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:af557050fd011a03d21dc26b31959033061a0443 commit r10--gaf557050fd011a03d21dc26b31959033061a0443 Author: Tobias Burnus Date: Fri Apr 17 19:08:55 2020 +0200 [OpenMP] Fix 'omp exit data' for Fortran arrays (PR 94635) PR middle-end/94635 * gimplify.c (gimplify_scan_omp_clauses): Turn MAP_TO_PSET to MAP_DELETE. PR middle-end/94635 * testsuite/libgomp.fortran/target-enter-data-2.F90: New.
[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94623 --- Comment #1 from Iain Buclaw --- Needs more host/target information.
[Bug driver/90983] manual documents `-Wno-stack-usage` flag, but it is unrecognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90983
--- Comment #5 from Torsten Robitzki ---
(In reply to Martin Sebor from comment #4)
> Using a very large -Wstack-usage argument should effectively disable the
> warning. E.g., -Wstack-usage=4EiB or -Wstack-usage=$(getconf ULONG_MAX).
Unfortunately, not when the stack usage is reported as unbound:
#include
int foo(int i)
{
void* p = alloca(i);
return p != 0;
}
int main()
{
foo(4000);
return 0;
}
$ arm-none-eabi-gcc t.c -Wstack-usage=200 -Wstack-usage=4EiB
t.c: In function 'foo':
t.c:3:5: warning: stack usage might be unbounded [-Wstack-usage=]
3 | int foo(int i)
| ^~~
[Bug driver/90392] Bogus value for %u in LINK_PLUGIN_SPEC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90392 Jeffrey A. Law changed: What|Removed |Added Status|WAITING |NEW Summary|[8/9/10 Regression] |Bogus value for %u in |Assertion failure in|LINK_PLUGIN_SPEC |ldlang.c:6868 when | |compiling with -flto| --- Comment #13 from Jeffrey A. Law --- Updating summary, dropping regression marker. Behavior seen as far back as gcc-6, probably started before then. Given the dl.res has been consistent, it's most likely not memory corruption -- if it were memory corruption I'd expect to see different results over time rather than the consistent "dl.res" output for %u.res.
