[Bug debug/93888] Incorrect DW_AT_location generated for copy-constructed function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93888 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:64ba6d17022eeb65f56f0b141c2640f9ab938f97 commit r10-7014-g64ba6d17022eeb65f56f0b141c2640f9ab938f97 Author: Jakub Jelinek Date: Wed Mar 4 12:59:04 2020 +0100 inliner: Copy DECL_BY_REFERENCE in copy_decl_to_var [PR93888] In the following testcase we emit wrong debug info for the karg parameter in the DW_TAG_inlined_subroutine into main. The problem is that the karg PARM_DECL is DECL_BY_REFERENCE and thus in the IL has const K & type, but in the source just const K. When the function is inlined, we create a VAR_DECL for it, but don't set DECL_BY_REFERENCE, so when emitting DW_AT_location, we treat it like a const K & typed variable, but it has DW_AT_abstract_origin which has just the const K type and thus the debugger thinks the variable has const K type. Fixed by copying the DECL_BY_REFERENCE flag. Not doing it in copy_decl_for_dup_finish, because copy_decl_no_change already copies that flag through copy_node and in copy_result_decl_to_var it is undesirable, as we handle DECL_BY_REFERENCE in that case instead by changing the type. 2020-03-04 Jakub Jelinek PR debug/93888 * tree-inline.c (copy_decl_to_var): Copy DECL_BY_REFERENCE flag. * g++.dg/guality/pr93888.C: New test.
[Bug target/91855] [8/9 Regression] OpenJDK Zero VM segfaults on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91855 John Paul Adrian Glaubitz changed: What|Removed |Added Version|9.2.1 |10.0 --- Comment #10 from John Paul Adrian Glaubitz --- Okay, this is interesting. I just tried again to reproduce the problem and it does not reproduce with GCC-8 and GCC-9 anymore but it does reproduce with GCC-10. Changing the affected version to 10.0, accordingly.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #38 from Thomas Henlich --- (In reply to Thomas Henlich from comment #37) > It would make sense to keep optimization in mind: > > Several calls to conversions of the same value should be performed only once. > > As a special case: Calls to compute sind(x) and cosd(x) should be optimized > to a conversion, followed by a call to sincos. > > The conversion could also be provided as a user function, for example in > code like y=tand(x)-deg2rad(x) the conversion would need to be performed > only once. I just realized this is probably a lot harder than it sounds, since it is incompatible with some of the range reduction steps, or at the least requires some further folding into x <= 45 for sincos to get sufficient accuracy. On the other hand side, always folding sind(45...90) to cosd(45...0) and cosd(45...90) to sind(45...0) probably wouldn't be such a bad thing.
[Bug fortran/93462] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93462 --- Comment #8 from CVS Commits --- The releases/gcc-8 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:6352c50d06a8ca0157293ecb0ef1f8a6dc19148a commit r8-10110-g6352c50d06a8ca0157293ecb0ef1f8a6dc19148a Author: Tobias Burnus Date: Wed Mar 4 13:29:25 2020 +0100 [Fortran] Disable front-end optimization for OpenACC atomic (PR93462) Backported from mainline 2020-01-31 Tobias Burnus PR fortran/93462 * frontend-passes.c (gfc_code_walker): For EXEC_OACC_ATOMIC, set in_omp_atomic to true prevent front-end optimization. PR fortran/93462 * gfortran.dg/goacc/atomic-1.f90: New.
[Bug fortran/93462] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93462 Tobias Burnus changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Tobias Burnus --- FIXED – as the fix has now been backported to GCC 8 (= 8.4.1), the oldest open branch. (In reply to Thomas Schwinge from comment #6) > Also needed on releases/gcc-8, to avoid introducing a regression, since […] > "backport: re PR fortran/92977 […]" I am not sure I understand this argument. The backported fix for OpenMP makes it easier to fix OpenACC (as it is then only one line), but by itself, the OpenMP commit does not affect the status of the OpenACC issue. (Whether an ICE caused by a new feature is a regression only because it was rejected before the new feature is also the question. But as the fix is trivial, backporting was/is fine.)
[Bug middle-end/91623] [8 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623 --- Comment #18 from David Seifert --- (In reply to Jakub Jelinek from comment #17) > Can't reproduce, compiles without any ICE since the above mentioned commits. > In #c15 you are clearing testing with GCC 9.2.0, but that is expected, the > bug has not been fixed in 9.2.0 which has been released in August 2019, but > rather has been backported to the 9 branch in October 2019, so you need at > least 9.2.1 20191022 snapshot Just verified, fixed with GCC 8.4, thanks again for the prompt response.
[Bug middle-end/91623] [8 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623 --- Comment #19 from David Seifert --- (In reply to Jakub Jelinek from comment #17) > Can't reproduce, compiles without any ICE since the above mentioned commits. > In #c15 you are clearing testing with GCC 9.2.0, but that is expected, the > bug has not been fixed in 9.2.0 which has been released in August 2019, but > rather has been backported to the 9 branch in October 2019, so you need at > least 9.2.1 20191022 snapshot Would it be possible to just get the code backport to GCC 7 too? I know the GCC 7 branch is closed, but we could add the patch in Gentoo. I tried backporting your mainline patch but compilation bailed out on missing "vector_cst_elt".
[Bug fortran/93462] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93462 --- Comment #10 from Thomas Schwinge --- (In reply to Tobias Burnus from comment #9) > (In reply to Thomas Schwinge from comment #6) > > Also needed on releases/gcc-8, to avoid introducing a regression, since […] > > "backport: re PR fortran/92977 […]" > > I am not sure I understand this argument. The backported fix for OpenMP > makes it easier to fix OpenACC (as it is then only one line), but by itself, > the OpenMP commit does not affect the status of the OpenACC issue. Ah, sorry, I had gotten that wrong: I thought the PR92977 commit introduced the "OpenACC regression", which is wrong; thanks for clarifying.
[Bug c++/93465] [10 Regression] ICE in oacc_verify_routine_clauses, at omp-general.c:1802 since r10-471-gb48f44bf77a39fef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93465 --- Comment #4 from Jakub Jelinek --- Thomas, can I ping on this?
[Bug c++/93314] [8/9/10 Regression] Invalid use of non-static data member causes ICE in gimplify_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93314 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Jason, your thoughts on this?
[Bug target/87560] ICE in curr_insn_transform, at lra-constraints.c:3892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87560 --- Comment #8 from CVS Commits --- The master branch has been updated by William Schmidt : https://gcc.gnu.org/g:0b0908c1f27d12a3cbbd3c9fd55aec1fe87586a6 commit r10-7020-g0b0908c1f27d12a3cbbd3c9fd55aec1fe87586a6 Author: Bill Schmidt Date: Wed Mar 4 07:30:29 2020 -0600 rs6000: Fix -mpower9-vector -mno-altivec ICE (PR87560) PR87560 reports an ICE when a test case is compiled with -mpower9-vector and -mno-altivec. This patch terminates compilation with an error when this combination (and other unreasonable ones) are requested. Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions. Reported error is now: f951: Error: '-mno-altivec' turns off '-mpower9-vector' 2020-03-02 Bill Schmidt PR target/87560 * rs6000-cpus.def (OTHER_ALTIVEC_MASKS): New #define. * rs6000.c (rs6000_disable_incompatible_switches): Add table entry for OPTION_MASK_ALTIVEC.
[Bug testsuite/81690] libgomp.c/{target-32,thread-limit-2}.c fail for nvptx: missing usleep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81690
--- Comment #6 from Tobias Burnus ---
Regarding {target-32.c, thread-limit-2.c}, see
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00422.html
for a busy-wait implementation, which was supposed get rewritten (see next
message in thread) "using declare variant".
[Bug target/87560] ICE in curr_insn_transform, at lra-constraints.c:3892
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87560 --- Comment #9 from Bill Schmidt --- I plan to backport the fix to releases/gcc-9 after 9.3 releases.
[Bug testsuite/81690] libgomp.c/{target-32,thread-limit-2}.c fail for nvptx: missing usleep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81690 --- Comment #7 from Tobias Burnus --- (In reply to Tobias Burnus from comment #6) > for a busy-wait implementation, which was supposed get rewritten (see next > message in thread) "using declare variant". The missing bit referenced there is: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01493.html
[Bug middle-end/93399] [8/9/10 Regression] Annotate assembler option failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93399 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 47969 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47969&action=edit gcc10-pr93399.patch Untested fix. This function is what we use in the gimple dumps for the DEBUG_STMTs with STRING_CST values.
[Bug fortran/94030] ICE equivalence of an integer and an element of an array of size n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94030 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-04 CC||marxin at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started to ICE with r6-635-g9b7df66f80888ba9, before that the code was rejected with: integer :: arr(n) 1 Error: Variable ‘n’ at (1) in this context must be constant pr94030.f90:5:17: equivalence (i, arr(1)) 1 Error: Array ‘arr’ at (1) with non-constant bounds cannot be an EQUIVALENCE object
[Bug analyzer/94028] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94028 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-03-04 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/93949] [8/9/10 Regression] Register const local var will not compile since r0-58166
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93949 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed for 8.5+, 9.3+ and 10+.
[Bug c/93949] [8/9/10 Regression] Register const local var will not compile since r0-58166
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93949 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a9e9ff7b8a4d10ccf54dd4a641dd55c1b1645e17 commit r8-10111-ga9e9ff7b8a4d10ccf54dd4a641dd55c1b1645e17 Author: Jakub Jelinek Date: Thu Feb 27 10:45:30 2020 +0100 gimplify: Don't optimize register const vars to static [PR93949] The following testcase is rejected, while it was accepted in 3.4 and earlier (before tree-ssa merge). The problem is that we decide to promote the const variable to TREE_STATIC, but TREE_STATIC DECL_REGISTER VAR_DECLs may only be the global register vars and so assemble_variable/make_decl_rtl diagnoses it. Either we do what the following patch does, where we could consider register as a hint the user doesn't want such optimization, because if something is forced static, it is not "register" anymore and register static is not valid in C either, or we could clear DECL_REGISTER instead, but would still need to punt at least on DECL_HARD_REGISTER cases. 2020-02-27 Jakub Jelinek PR c/93949 * gimplify.c (gimplify_init_constructor): Don't promote readonly DECL_REGISTER variables to TREE_STATIC. * gcc.c-torture/compile/pr93949.c: New test.
[Bug middle-end/93465] [10 Regression] ICE in oacc_verify_routine_clauses, at omp-general.c:1802 since r10-471-gb48f44bf77a39fef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93465 Thomas Schwinge changed: What|Removed |Added Keywords|ice-on-invalid-code |openmp Status|NEW |ASSIGNED Last reconfirmed|2020-01-28 00:00:00 |2020-3-4 Component|c++ |middle-end Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org --- Comment #5 from Thomas Schwinge --- ACK, thanks for the report and initial analysis. Not sure if this is actually supposed to be valid or invalid code (but of course we shouldn't ICE either way). That GCC 9 accepts this doesn't mean too much, given that we don't know what it's supposed to mean. Until the interactions between OpenACC and OpenMP 'target' get defined properly, I suggest we make this a compile-time error. I'm testing a patch. (Not sure if a variant of that will be worth backporting to release branches, too?)
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #39 from Steve Kargl --- On Wed, Mar 04, 2020 at 12:07:18PM +, thenlich at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 > > On the other hand side, always folding sind(45...90) to cosd(45...0) and > cosd(45...90) to sind(45...0) probably wouldn't be such a bad thing. > It is not only a good thing, it is required to get small max ULP near zero crossings. Testing fma is as accurate and as fast as the bit twiddling methods I devised. I haven't verified, but it seems gcc inlines fma, which likely is bit twiddling.
[Bug middle-end/94004] [8/9/10 Regression] missing -Walloca on calls to alloca due to -Wno-system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94004 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- (In reply to Martin Sebor from comment #2) > Bisection points to r254630 which doesn't look related to -Walloca: It is related, in particular the https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/gimple.c?limit_changes=0&r1=254630&r2=254629&pathrev=254630 hunk. * gimple.c (gimple_build_call_from_tree): Set call location. which sets the location on the __builtin_alloca call newly to one with sysp = true flag.
[Bug bootstrap/93962] [10 regression] bootstrap fails with gcc/value-prof.c:268:28 : error: format '%lld' expects argument of type 'long long int', but argument 3 hastype 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93962 --- Comment #5 from Jeffrey A. Law --- Absolutely.
[Bug rtl-optimization/93159] [10 Regression] ICE (segfault) during RTL pass on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93159 --- Comment #4 from Jakub Jelinek --- Ping.
[Bug debug/93888] Incorrect DW_AT_location generated for copy-constructed function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93888 --- Comment #5 from Mike Gulick --- Thanks Jakub! I can confirm that this fixes the issue for me.
[Bug analyzer/93993] ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93993
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:3d66e153b40ed000af30a9e569a05f34d5d576aa
commit r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa
Author: David Malcolm
Date: Tue Mar 3 10:53:04 2020 -0500
analyzer: fix ICE on non-lvalue in prune_for_sm_diagnostic [PR93993]
PR analyzer/93993 reports another ICE within
diagnostic_manager::prune_for_sm_diagnostic in which the expression
of interest becomes a non-lvalue (similar to PR 93544, PR 93647, and
PR 93950), due to attempting to get an lvalue for a non-lvalue with a
NULL context, leading to an ICE when the failure is reported to
make_region_for_unexpected_tree_code. The tree in question is
an ADDR_EXPR of a VAR_DECL, due to:
event 11: switching var of interest from ‘tm’ in callee to ‘&qb’ in
caller
This patch adds more bulletproofing to the routine by introducing
a tentative_region_model_context class that can be passed in such
circumstances which records that an error occurred, and then
checking to see if an error was recorded, thus avoiding the ICE.
This is papering over the problem, but a better solution seems more
like stage 1 material.
The patch also refactors the error-checking for CONSTANT_CLASS_P.
The testcase pr93993.f90 has a false positive:
pr93993.f90:19:0:
19 | allocate (tm) ! { dg-warning "dereference of possibly-NULL" }
|
Warning: dereference of possibly-NULL ‘_6’ [CWE-690]
[-Wanalyzer-possible-null-dereference]
which appears to be a pre-existing bug affecting any allocate call in
Fortran, which I will fix in a followup.
gcc/analyzer/ChangeLog:
PR analyzer/93993
* checker-path.h (state_change_event::get_lvalue): Add ctxt param
and pass it to region_model::get_value call.
* diagnostic-manager.cc (get_any_origin): Pass a
tentative_region_model_context to the calls to get_lvalue and reject
the comparison if errors occur.
(can_be_expr_of_interest_p): New function.
(diagnostic_manager::prune_for_sm_diagnostic): Replace checks for
CONSTANT_CLASS_P with calls to update_for_unsuitable_sm_exprs.
Pass a tentative_region_model_context to the calls to
state_change_event::get_lvalue and reject the comparison if errors
occur.
(diagnostic_manager::update_for_unsuitable_sm_exprs): New.
* diagnostic-manager.h
(diagnostic_manager::update_for_unsuitable_sm_exprs): New decl.
* region-model.h (class tentative_region_model_context): New class.
gcc/testsuite/ChangeLog:
PR analyzer/93993
* gfortran.dg/analyzer/pr93993.f90: New test.
[Bug analyzer/93950] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93950
--- Comment #4 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:3d66e153b40ed000af30a9e569a05f34d5d576aa
commit r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa
Author: David Malcolm
Date: Tue Mar 3 10:53:04 2020 -0500
analyzer: fix ICE on non-lvalue in prune_for_sm_diagnostic [PR93993]
PR analyzer/93993 reports another ICE within
diagnostic_manager::prune_for_sm_diagnostic in which the expression
of interest becomes a non-lvalue (similar to PR 93544, PR 93647, and
PR 93950), due to attempting to get an lvalue for a non-lvalue with a
NULL context, leading to an ICE when the failure is reported to
make_region_for_unexpected_tree_code. The tree in question is
an ADDR_EXPR of a VAR_DECL, due to:
event 11: switching var of interest from ‘tm’ in callee to ‘&qb’ in
caller
This patch adds more bulletproofing to the routine by introducing
a tentative_region_model_context class that can be passed in such
circumstances which records that an error occurred, and then
checking to see if an error was recorded, thus avoiding the ICE.
This is papering over the problem, but a better solution seems more
like stage 1 material.
The patch also refactors the error-checking for CONSTANT_CLASS_P.
The testcase pr93993.f90 has a false positive:
pr93993.f90:19:0:
19 | allocate (tm) ! { dg-warning "dereference of possibly-NULL" }
|
Warning: dereference of possibly-NULL ‘_6’ [CWE-690]
[-Wanalyzer-possible-null-dereference]
which appears to be a pre-existing bug affecting any allocate call in
Fortran, which I will fix in a followup.
gcc/analyzer/ChangeLog:
PR analyzer/93993
* checker-path.h (state_change_event::get_lvalue): Add ctxt param
and pass it to region_model::get_value call.
* diagnostic-manager.cc (get_any_origin): Pass a
tentative_region_model_context to the calls to get_lvalue and reject
the comparison if errors occur.
(can_be_expr_of_interest_p): New function.
(diagnostic_manager::prune_for_sm_diagnostic): Replace checks for
CONSTANT_CLASS_P with calls to update_for_unsuitable_sm_exprs.
Pass a tentative_region_model_context to the calls to
state_change_event::get_lvalue and reject the comparison if errors
occur.
(diagnostic_manager::update_for_unsuitable_sm_exprs): New.
* diagnostic-manager.h
(diagnostic_manager::update_for_unsuitable_sm_exprs): New decl.
* region-model.h (class tentative_region_model_context): New class.
gcc/testsuite/ChangeLog:
PR analyzer/93993
* gfortran.dg/analyzer/pr93993.f90: New test.
[Bug analyzer/93647] ICE in get_lvalue_1, at analyzer/region-model.cc:4613
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93647
--- Comment #4 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:3d66e153b40ed000af30a9e569a05f34d5d576aa
commit r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa
Author: David Malcolm
Date: Tue Mar 3 10:53:04 2020 -0500
analyzer: fix ICE on non-lvalue in prune_for_sm_diagnostic [PR93993]
PR analyzer/93993 reports another ICE within
diagnostic_manager::prune_for_sm_diagnostic in which the expression
of interest becomes a non-lvalue (similar to PR 93544, PR 93647, and
PR 93950), due to attempting to get an lvalue for a non-lvalue with a
NULL context, leading to an ICE when the failure is reported to
make_region_for_unexpected_tree_code. The tree in question is
an ADDR_EXPR of a VAR_DECL, due to:
event 11: switching var of interest from ‘tm’ in callee to ‘&qb’ in
caller
This patch adds more bulletproofing to the routine by introducing
a tentative_region_model_context class that can be passed in such
circumstances which records that an error occurred, and then
checking to see if an error was recorded, thus avoiding the ICE.
This is papering over the problem, but a better solution seems more
like stage 1 material.
The patch also refactors the error-checking for CONSTANT_CLASS_P.
The testcase pr93993.f90 has a false positive:
pr93993.f90:19:0:
19 | allocate (tm) ! { dg-warning "dereference of possibly-NULL" }
|
Warning: dereference of possibly-NULL ‘_6’ [CWE-690]
[-Wanalyzer-possible-null-dereference]
which appears to be a pre-existing bug affecting any allocate call in
Fortran, which I will fix in a followup.
gcc/analyzer/ChangeLog:
PR analyzer/93993
* checker-path.h (state_change_event::get_lvalue): Add ctxt param
and pass it to region_model::get_value call.
* diagnostic-manager.cc (get_any_origin): Pass a
tentative_region_model_context to the calls to get_lvalue and reject
the comparison if errors occur.
(can_be_expr_of_interest_p): New function.
(diagnostic_manager::prune_for_sm_diagnostic): Replace checks for
CONSTANT_CLASS_P with calls to update_for_unsuitable_sm_exprs.
Pass a tentative_region_model_context to the calls to
state_change_event::get_lvalue and reject the comparison if errors
occur.
(diagnostic_manager::update_for_unsuitable_sm_exprs): New.
* diagnostic-manager.h
(diagnostic_manager::update_for_unsuitable_sm_exprs): New decl.
* region-model.h (class tentative_region_model_context): New class.
gcc/testsuite/ChangeLog:
PR analyzer/93993
* gfortran.dg/analyzer/pr93993.f90: New test.
[Bug analyzer/93544] ICE in get_lvalue_1, at analyzer/region-model.cc:4613
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93544
--- Comment #8 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:3d66e153b40ed000af30a9e569a05f34d5d576aa
commit r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa
Author: David Malcolm
Date: Tue Mar 3 10:53:04 2020 -0500
analyzer: fix ICE on non-lvalue in prune_for_sm_diagnostic [PR93993]
PR analyzer/93993 reports another ICE within
diagnostic_manager::prune_for_sm_diagnostic in which the expression
of interest becomes a non-lvalue (similar to PR 93544, PR 93647, and
PR 93950), due to attempting to get an lvalue for a non-lvalue with a
NULL context, leading to an ICE when the failure is reported to
make_region_for_unexpected_tree_code. The tree in question is
an ADDR_EXPR of a VAR_DECL, due to:
event 11: switching var of interest from ‘tm’ in callee to ‘&qb’ in
caller
This patch adds more bulletproofing to the routine by introducing
a tentative_region_model_context class that can be passed in such
circumstances which records that an error occurred, and then
checking to see if an error was recorded, thus avoiding the ICE.
This is papering over the problem, but a better solution seems more
like stage 1 material.
The patch also refactors the error-checking for CONSTANT_CLASS_P.
The testcase pr93993.f90 has a false positive:
pr93993.f90:19:0:
19 | allocate (tm) ! { dg-warning "dereference of possibly-NULL" }
|
Warning: dereference of possibly-NULL ‘_6’ [CWE-690]
[-Wanalyzer-possible-null-dereference]
which appears to be a pre-existing bug affecting any allocate call in
Fortran, which I will fix in a followup.
gcc/analyzer/ChangeLog:
PR analyzer/93993
* checker-path.h (state_change_event::get_lvalue): Add ctxt param
and pass it to region_model::get_value call.
* diagnostic-manager.cc (get_any_origin): Pass a
tentative_region_model_context to the calls to get_lvalue and reject
the comparison if errors occur.
(can_be_expr_of_interest_p): New function.
(diagnostic_manager::prune_for_sm_diagnostic): Replace checks for
CONSTANT_CLASS_P with calls to update_for_unsuitable_sm_exprs.
Pass a tentative_region_model_context to the calls to
state_change_event::get_lvalue and reject the comparison if errors
occur.
(diagnostic_manager::update_for_unsuitable_sm_exprs): New.
* diagnostic-manager.h
(diagnostic_manager::update_for_unsuitable_sm_exprs): New decl.
* region-model.h (class tentative_region_model_context): New class.
gcc/testsuite/ChangeLog:
PR analyzer/93993
* gfortran.dg/analyzer/pr93993.f90: New test.
[Bug analyzer/93993] ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93993
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:e516294a1acb28d44cfd583cc6a80354044e
commit r10-7024-ge516294a1acb28d44cfd583cc6a80354044e
Author: David Malcolm
Date: Tue Mar 3 16:36:13 2020 -0500
analyzer: handle __builtin_expect [PR93993]
The false warning:
pr93993.f90:19:0:
19 | allocate (tm) ! { dg-warning "dereference of possibly-NULL" }
|
Warning: dereference of possibly-NULL ‘_6’ [CWE-690]
[-Wanalyzer-possible-null-dereference]
in the reproducer for PR analyzer/93993 is due to a BUILTIN_EXPECT in
the chain of SSA expressions between the malloc and the condition
guarding the edge: the analyzer didn't "know" about the relationship
between initial argument to BUILTIN_EXPECT and the return value.
This patch implements support for BUILTIN_EXPECT so that the return
value is known to be equal to the initial argument. This adds
constraints when exploring the CFG edges, eliminating the above
false positive.
Doing so also eliminated the leak warning from the reproducer. The
issue was that leaked_pvs was empty within
impl_region_model_context::on_state_leak, due to the leaking region
being a view, of type struct Pdtet_8 *, of a region of type
struct pdtet_8 *, which led region_model::get_representative_path_var to
return a NULL_TREE value.
Hence the patch also implements view support for
region_model::get_representative_path_var, restoring the leak
diagnostic, albeit changing the wording to:
Warning: leak of ‘(struct Pdtet_8) qb’ [CWE-401] [-Wanalyzer-malloc-leak]
It's not clear to me if we should emit leaks at a fortran "end program"
(currently we suppress them for leaks at the end of main).
gcc/analyzer/ChangeLog:
PR analyzer/93993
* region-model.cc (region_model::on_call_pre): Handle
BUILT_IN_EXPECT and its variants.
(region_model::add_any_constraints_from_ssa_def_stmt): Split out
gassign handling into add_any_constraints_from_gassign; add gcall
handling.
(region_model::add_any_constraints_from_gassign): New function,
based on the above. Add handling for NOP_EXPR.
(region_model::add_any_constraints_from_gcall): New function.
(region_model::get_representative_path_var): Handle views.
* region-model.h
(region_model::add_any_constraints_from_ssa_def_stmt): New decl.
(region_model::add_any_constraints_from_gassign): New decl.
gcc/testsuite/ChangeLog:
PR analyzer/93993
* gcc.dg/analyzer/expect-1.c: New test.
* gcc.dg/analyzer/malloc-4.c: New test.
* gfortran.dg/analyzer/pr93993.f90: Remove xfail from dg-bogus.
Move location of leak warning and update message.
[Bug analyzer/93993] ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93993 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- The ICE should be fixed by r10-7024-ge516294a1acb28d44cfd583cc6a80354044e.
[Bug bootstrap/93962] [10 regression] bootstrap fails with gcc/value-prof.c:268:28 : error: format '%lld' expects argument of type 'long long int', but argument 3 hastype 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93962 --- Comment #6 from Gerald Pfeifer --- (In reply to Jeffrey A. Law from comment #3) > Gerald, I wanted to reproduce the error so that I could in turn verify the > proposed fix of using std:abs would work. I verified that the fix of using std::abs works in the situation where I had failures without. > So I installed FreeBSD 11.3 (i686) in a VM. Bootstrap with GCC went fine. > I couldn't get the failure building with clang either. I looked into this. Indeed my regular bootstraps do not fail, even without this patch. It is building the lang/gcc10-devel port, based on our weekly snapshots, that exhibited this behavior. > How are you configuring & building? Are you familiar with the FreeBSD ports system? The port resides in ports/lang/gcc10-devel and to reproduce the issue you need to remove ports/lang/gcc10-devel/files/patch-value-prof.c-buildfix that I added. I have not found yet why a "regular" bootstrap succeeds and fails in my environment when I build it as a port, but will try to dig into it this evening. > So while I believe Andrew is right that this should be using std::abs, I'd > still like to reproduce the problem and verify that using std::abs is > sufficient to fix. The fix is confirmed, and part of the FreeBSD ports tree now. However, I am not yet able to explain why it does occur in one case and not in the other.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #40 from Thomas Henlich --- Now I get it, symmetry is beautiful: Both sin(x) and cos(x) for any x can always be calculated with one range reduction to 0...45, one call to sincos(), and a sign transfer for each result.
[Bug libstdc++/94032] New: Please provide std::string::__resize_default_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94032 Bug ID: 94032 Summary: Please provide std::string::__resize_default_init Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rafael at espindo dot la Target Milestone: --- There is a c++ proposal at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1072r5.html and libc++ already has an implementation that is used by abseil: https://github.com/abseil/abseil-cpp/blob/12bc53e0318d80569270a5b26ccbc62b52022b89/absl/strings/internal/resize_uninitialized.h#L39
[Bug target/93800] [9/10 Regression] GCC adds unwanted nops to align loops on powerpc 8xx since r9-1623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93800 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-04 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||segher at gcc dot gnu.org Summary|[9/10 Regression] GCC adds |[9/10 Regression] GCC adds |unwanted nops to align |unwanted nops to align |loops on powerpc 8xx|loops on powerpc 8xx since ||r9-1623 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r9-1623-gc518c1025b435e1c593a745036fc9b8ed04c5819. At first I thought it is because of the rs6000.c changes, where previously it was using 15 in the last two spots, but now "16" like in the earlier cases, but most likely it is some other change. Martin, can you please have a look?
[Bug tree-optimization/94021] -Wformat-truncation false positive due to excessive integer range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94021 --- Comment #7 from Martin Sebor --- Since the merge with the sprintf pass, the strlen pass has an instance of EVRP that it passes to sprintf to get range info from (it also uses it itself in places).
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #41 from Thomas Henlich --- One would assume that fast FMA (https://en.wikipedia.org/wiki/FMA_instruction_set) is or will be available to the modern Fortran enthusiast, in the year 202x.
[Bug libstdc++/94033] New: is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033
Bug ID: 94033
Summary: is_trivially_copy_constructible<> fails with compiler
error on complicated object with private default
constructor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
gcc 10 regression: the same source file builds in gcc 9. The preprocessed file
from gcc 10 fails on gcc 9 with the same error, so the bug is likely in
libstdc++.
Error trail:
g++ -MD -MT build/dev/database.o -MF build/dev/database.o.d
-I/home/avi/scylla/seastar/include
-I/home/avi/scylla/build/dev/seastar/gen/include -std=gnu++17 -U_FORTIFY_SOURCE
-Wno-maybe-uninitialized -Werror=unused-result -fstack-clash-protection
-fconcepts -DSEASTAR_API_LEVEL=2 -DSEASTAR_HAVE_GCC6_CONCEPTS
-DSEASTAR_USE_STD_OPTIONAL_VARIANT_STRINGVIEW -DSEASTAR_TYPE_ERASE_MORE
-DFMT_LOCALE -DFMT_SHARED -I/usr/include/p11-kit-1 -O1
-DSEASTAR_ENABLE_ALLOC_FAILURE_INJECTION -I. -I build/dev/gen -march=westmere
-DBOOST_TEST_DYN_LINK -fvisibility=hidden -Wall -Werror -Wno-mismatched-tags
-Wno-maybe-uninitialized -Wno-tautological-compare -Wno-missing-braces
-Wno-misleading-indentation -Wno-overflow -Wno-noexcept-type
-Wno-nonnull-compare -Wno-error=cpp -Wno-ignored-attributes
-Wno-overloaded-virtual -Wno-stringop-overflow
-Wno-error=deprecated-declarations -DXXH_PRIVATE_API -DSEASTAR_TESTING_MAIN
-DHAVE_LIBSYSTEMD=1 -DHAVE_LZ4_COMPRESS_DEFAULT -c -o build/dev/database.o
database.cc
In file included from /usr/include/c++/10/bits/move.h:57,
from /usr/include/c++/10/bits/stl_pair.h:59,
from /usr/include/c++/10/utility:70,
from
/home/avi/scylla/seastar/include/seastar/core/shared_ptr.hh:25,
from dht/i_partitioner.hh:43,
from database.hh:25,
from database.cc:22:
/usr/include/c++/10/type_traits: In instantiation of ‘struct
std::__is_nt_default_constructible_atom’:
/usr/include/c++/10/type_traits:976:12: required from ‘struct
std::__is_nt_default_constructible_impl’
/usr/include/c++/10/type_traits:138:12: required from ‘struct
std::__and_,
std::__is_nt_default_constructible_impl >’
/usr/include/c++/10/type_traits:987:12: required from ‘struct
std::is_nothrow_default_constructible’
/usr/include/c++/10/type_traits:133:12: required from ‘struct
std::__and_ >’
/usr/include/c++/10/tuple:623:2: required from ‘constexpr
std::tuple<_Elements>::tuple() [with _Dummy = void; typename
std::enable_if::value, _Elements
...>::__is_explicitly_default_constructible(), bool>::type = false;
_Elements = {mutation}]’
/usr/include/c++/10/type_traits:1183:30: required from ‘struct
std::is_trivially_constructible >’
/home/avi/scylla/seastar/include/seastar/core/future.hh:210:51: required from
‘constexpr const bool seastar::internal::can_inherit >’
/home/avi/scylla/seastar/include/seastar/core/future.hh:217:44: required from
‘struct seastar::internal::uninitialized_wrapper >’
/home/avi/scylla/seastar/include/seastar/core/future.hh:395:8: required from
‘struct seastar::future_state’
/home/avi/scylla/seastar/include/seastar/core/future.hh:962:24: required from
‘class seastar::future’
database.cc:45:126: required from here
/usr/include/c++/10/type_traits:962:47: error: ‘constexpr mutation::mutation()’
is private within this context
962 | : public integral_constant
| ^
In file included from database.hh:65,
from database.cc:22:
mutation.hh:49:5: note: declared private here
49 | mutation() = default;
| ^~~~
I have a reproducer, but it is 400k lines long after preprocessing. I'll spend
some time minimizing it and post it.
[Bug bootstrap/93962] [10 regression] bootstrap fails with gcc/value-prof.c:268:28 : error: format '%lld' expects argument of type 'long long int', but argument 3 hastype 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93962 --- Comment #7 from Jakub Jelinek --- So do you think you could attach preprocessed sources from both the working and failing builds so that we can look up at the differences?
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #42 from Steve Kargl --- On Wed, Mar 04, 2020 at 04:35:02PM +, thenlich at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 > > --- Comment #41 from Thomas Henlich --- > One would assume that fast FMA > (https://en.wikipedia.org/wiki/FMA_instruction_set) is or will be available to > the modern Fortran enthusiast, in the year 202x. > It already is. F2018, 17.11.3 IEEE_FMA. gfortran currently does not implement IEEE_FMA along with a few additional IEEE_ARITHMETIC features added in F2018. Note, gcc/builtins.def has fma, fmaf, and fmal covered. We'll need a mapping in libquadmath if it has a __float128 fma.
[Bug libstdc++/94032] Please provide std::string::__resize_default_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94032 --- Comment #1 from Jonathan Wakely --- We'll add it when it's in the draft standard. Adding it before then would either mean only making it available for C++20 mode, or adding it to the shared library exports as a stable ABI artefact. Neither seems very good to me.
[Bug tree-optimization/83733] -Wformat-overflow false positive for %d on bounded integer when inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83733
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=94021
Known to fail||10.0, 7.3.0, 8.2.0, 9.1.0
--- Comment #4 from Martin Sebor ---
GCC 10 issues the same warning. The partial dump below shows that the range
info the directive uses doesn't correspond to the range set in the code. This
is similar to pr94021.
$ gcc -O2 -S -Wall -fdump-tree-strlen=/dev/stdout pr83733.c
;; Function g (g, funcdef_no=1, decl_uid=1939, cgraph_uid=2, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4 5 6 7
;; 2 succs { 7 3 }
;; 3 succs { 4 6 }
;; 4 succs { 7 5 }
;; 5 succs { 6 }
;; 6 succs { 7 }
;; 7 succs { 1 }
Computing maximum subobject size for _10:
Computing maximum object size for p_8(D):
_10: maximum subobject size 9
pr83733.c:8: __builtin_sprintf: objsize = 9, fmtstr = "CMPRT%02d"
Directive 1 at offset 0: "CMPRT", length = 5
Result: 5, 5, 5, 5 (5, 5, 5, 5)
Directive 2 at offset 5: "%02d"
pr83733.c: In function ‘g’:
pr83733.c:8:34: warning: ‘%02d’ directive writing between 2 and 6 bytes into a
region of size 4 [-Wformat-overflow=]
8 | __builtin_sprintf (p->a, "CMPRT%02d", i);
| ^~~~
pr83733.c:8:28: note: directive argument in the range [-32768, 31]
8 | __builtin_sprintf (p->a, "CMPRT%02d", i);
|^~~
Result: 2, 6, 6, 6 (7, 11, 11, 11)
Directive 3 at offset 9: "", length = 1
pr83733.c:8:3: note: ‘__builtin_sprintf’ output between 8 and 12 bytes into a
destination of size 9
8 | __builtin_sprintf (p->a, "CMPRT%02d", i);
| ^~~~
[Bug c++/90432] [9/10 Regression] Internal compiler error with no_unique_address empty type with constructor call followed by value initialized to non-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90432 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libstdc++/94033] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #1 from Jonathan Wakely --- Probably another instance of PR 93983 and PR PR 93923.
[Bug c++/94025] Expected-to-fail compilation goes through by not detecting mutable-specifier on lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94025 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-04 Ever confirmed|0 |1
[Bug libstdc++/94003] is_constructible seems to have sideeffects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94003 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-04 Ever confirmed|0 |1
[Bug libstdc++/94033] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #2 from Avi Kivity --- It does not look similar to 93923. There, there is an incomplete type. In my reproducer the type is complete but the default constructor is private. Note that for simple cases is_trivially_constructible works (and evaluates to false), both in gcc 9 and gcc 10. It is only in a few cases that it starts to fail. The errors are also very different from 93983.
[Bug target/93800] [9/10 Regression] GCC adds unwanted nops to align loops on powerpc 8xx since r9-1623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93800 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Sure, let me take a look.
[Bug tree-optimization/81401] False positive sprintf warning at O2 (-Wformat-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81401 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Neither test case triggers the warning in GCC 10. Bisection points to r269115 as the fix.
[Bug tree-optimization/85741] [meta-bug] bogus/missing -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741 Bug 85741 depends on bug 81401, which changed state. Bug 81401 Summary: False positive sprintf warning at O2 (-Wformat-overflow) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81401 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/81401] False positive sprintf warning at O2 (-Wformat-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81401 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:3ca63e1c76b7693b5d3f5ba2567421defc764249 commit r10-7027-g3ca63e1c76b7693b5d3f5ba2567421defc764249 Author: Martin Sebor Date: Wed Mar 4 10:23:49 2020 -0700 PR middle-end/81401 - false positive -Wformat-overflow in a loop gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/builtin-sprintf-warn-24.c: New test.
[Bug analyzer/94028] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94028 --- Comment #1 from Zdenek Sojka --- I can no longer reproduce this with r10-7026 , seems to be fixed by r10-7023
[Bug c++/94034] New: Broken diagnostic: 'result_decl' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034
Bug ID: 94034
Summary: Broken diagnostic: 'result_decl' not supported by
dump_expr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
The following produces substitution text in an error message that is indicative
of missing format-for-message handling.
### SOURCE ():
struct A { A *ap = this; };
constexpr A foo() {
return {};
}
void g() {
constexpr A a = foo();
}
### COMPILER INVOCATION:
g++ -fsyntax-only -xc++ -
### COMPILER OUTPUT:
: In function 'void g()':
:6:23: error: 'A{(&'result_decl' not supported by dump_expr)}' is not a constant expression
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200302 (experimental) (GCC)
[Bug c++/91953] [8 Regression] G++ rejects lambda with constexpr variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91953 Jason Merrill changed: What|Removed |Added Summary|[8/9 Regression] G++|[8 Regression] G++ rejects |rejects lambda with |lambda with constexpr |constexpr variable |variable --- Comment #10 from Jason Merrill --- Fixed for 9.3 as well.
[Bug tree-optimization/80776] -Wformat-overflow false positive for %d on integer bounded by __builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80776
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2017-05-16 00:00:00 |2020-3-4
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=94021
Known to fail|6.3.0, 7.1.0|10.0, 6.4.0, 7.5.0, 8.4.0,
||9.2.0
--- Comment #7 from Martin Sebor ---
Reconfirming that test case in comment #2 still triggers the warning in GCC 10.
The dump shows that the warning thinks the fifth directive (%02d) generates
between 2 and 10 bytes of output. The symptoms feel similar to pr94021 but I
haven't looked into whether they underlying root causes are related.
Result: 2, 10, 10, 10 (12, 20, 20, 20)
$ gcc -O2 -S -Wall -fdump-tree-strlen=/dev/stdout pr80776-c2.c
;; Function f (f, funcdef_no=0, decl_uid=1936, cgraph_uid=1, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
pr80776-c2.c:14: __builtin_sprintf: objsize = 15, fmtstr =
"%04d%02d%02d%02d%02d%02d"
Directive 1 at offset 0: "%04d"
Result: 4, 4, 4, 4 (4, 4, 4, 4)
Directive 2 at offset 4: "%02d"
Result: 2, 2, 2, 2 (6, 6, 6, 6)
Directive 3 at offset 8: "%02d"
Result: 2, 2, 2, 2 (8, 8, 8, 8)
Directive 4 at offset 12: "%02d"
Result: 2, 2, 2, 2 (10, 10, 10, 10)
Directive 5 at offset 16: "%02d"
pr80776-c2.c: In function ‘f’:
pr80776-c2.c:14:44: warning: ‘%02d’ directive writing between 2 and 10 bytes
into a region of size 5 [-Wformat-overflow=]
14 | __builtin_sprintf (buf, "%04d%02d%02d%02d%02d%02d", a, b, c, d, e,
f);
|^~~~
pr80776-c2.c:14:27: note: directive argument in the range [0, 2147483647]
14 | __builtin_sprintf (buf, "%04d%02d%02d%02d%02d%02d", a, b, c, d, e,
f);
| ^~
Result: 2, 10, 10, 10 (12, 20, 20, 20)
Directive 6 at offset 20: "%02d"
pr80776-c2.c:14:27: note: directive argument in the range [0, 60]
Result: 2, 2, 2, 2 (14, 22, 22, 22)
Directive 7 at offset 24: "", length = 1
pr80776-c2.c:14:3: note: ‘__builtin_sprintf’ output between 15 and 23 bytes
into a destination of size 15
14 | __builtin_sprintf (buf, "%04d%02d%02d%02d%02d%02d", a, b, c, d, e,
f);
| ^
f (int a, int b, int c, int d, int e, int f)
{
[local count: 1073741824]:
__builtin_sprintf (&buf, "%04d%02d%02d%02d%02d%02d", a_14(D), b_15(D),
c_16(D), d_17(D), e_18(D), f_19(D));
return;
}
[Bug middle-end/94035] New: Wrong optimization: conditional equivalence vs. values with several representations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94035
Bug ID: 94035
Summary: Wrong optimization: conditional equivalence vs. values
with several representations
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
The problem happens when:
- conditional equivalence propagation replaces an expression with a variable or
a constant that has the same value but a different representation, and
- this happens in a computation where representation is accessed.
Example with a pseudo-denormal in long double:
--
#include
__attribute__((noipa,optnone)) // imagine it in a separate TU
static void *opaque(void *p) { return p; }
int main()
{
long double x, y;
unsigned char *px = (unsigned char *)&x;
unsigned char *py = (unsigned char *)&y;
// make x pseudo-denormal
x = 0;
px[7] = 0x80;
opaque(&x); // hide it from the optimizer
y = x;
if (y == 0x1p-16382l)
printf("py[8] = %d\n", py[8]);
printf("py[8] = %d\n", py[8]);
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra -Wno-attributes -O3 test.c && ./a.out
py[8] = 1
py[8] = 0
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200304 (experimental)
--
The value 0x1p-16382l admits two representations:
00 00 80 00 00 00 00 00 00 00 pseudo-denormal
00 01 80 00 00 00 00 00 00 00 normalized value
So both 0 and 1 for py[8] are fine but the testcase should print the same value
both times, i.e. the representation of y should be stable.
DR 260 Q1 allows for unstable representation but IMO this is wrong.
[Bug middle-end/94035] Wrong optimization: conditional equivalence vs. values with several representations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94035 --- Comment #1 from Alexander Cherepanov --- clang bug -- https://bugs.llvm.org/show_bug.cgi?id=45101
[Bug testsuite/94036] New: [9 regression] gcc.target/powerpc/pr72804.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94036 Bug ID: 94036 Summary: [9 regression] gcc.target/powerpc/pr72804.c fails Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- This was fixed in trunk, see pr92398, and the same fix should work for gcc 9. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92398 power 7: FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times not 4 FAIL: gcc.target/powerpc/pr72804.c scan-assembler-not lxvd2x FAIL: gcc.target/powerpc/pr72804.c scan-assembler-not stxvd2x power 8: works fine power 9: FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times not 4 FAIL: gcc.target/powerpc/pr72804.c scan-assembler-times std 2
[Bug c++/92601] [9 Regression] error: type variant differs by TYPE_NEEDS_CONSTRUCTING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92601 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed for 9.3.
[Bug middle-end/94004] [8/9/10 Regression] missing -Walloca on calls to alloca due to -Wno-system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94004 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-03-04 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1
[Bug analyzer/94028] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94028 --- Comment #2 from David Malcolm --- Yes, the ICE was fixed by r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa. It's a similar issue to the reproducer for PR analyzer/93993. I'll add your reproducer as a further regression test; thanks.
[Bug c++/91993] [8/9/10 Regression] Spurious -Wconversion warning with -fsanitize=undefined since r6-4886-gcda0a029f45d20f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91993
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
The sanitization boils down to adding COMPOUND_EXPRs with the checking in the
first operand and whatever it would normally have in the second operand.
using uc = unsigned char;
auto
foo (const uc &a, const uc &b, const uc &c)
{
return static_cast(static_cast(a << 1U) | b) | c;
}
auto
bar (const uc &a, const uc &b, const uc &c, int &d)
{
return static_cast(static_cast((d++, a) << 1U) | b) | c;
}
warns in bar the same even with just -Wconversion and doesn't warn in foo.
Now, I wonder if a way out of this wouldn't be in cp_build_binary_op to look
through COMPOUND_EXPRs (say set some temporary to (not sure if op0 or
orig_op0),
and then while (TREE_CODE (op0) == COMPOUND_EXPR) op0 = TREE_OPERAND (op0, 1);
and similarly for op1 (or orig_op1?) and then at the end readd the lhs's from
the COMPOUND_EXPRs to the result (guess for doing_shift case and
flag_strong_eval_order == 2 we'd need to either not do that or be extra
careful, because in that case op0 is ordered before op1).
Thoughts on this?
[Bug c++/36566] Cannot bind packed field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36566
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=93910,
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=92900,
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=68160,
||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=60972
--- Comment #12 from Eric Gallager ---
(In reply to Rene Rahn from comment #10)
> I know this is quite old now. But can someone explain me why using `#pragma
> pack(push, 1)` does work then? I couldn't find enough resources on that. The
> only thing I found is, that it does literally the same. But wouldn't then
> the references/pointers still not be valid?
>
> So if I change the code to:
>
> ```
> #pragma pack(push, 1)
> struct Squeeze
> {
> short s;
> };
> #pragma pack(pop)
> ```
>
> Then it works on godbolt with gcc-trunk.
There are several bugs open about inconsistencies between
__attribute__((packed)) and #pragma pack; see for example: bug 93910, bug
92900, bug 68160, and bug 60972
[Bug inline-asm/93981] No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981 --- Comment #15 from jwjagersma at gmail dot com --- Created attachment 47970 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47970&action=edit alternative patch v3 Alternative to last patch. Inserts the debug stmt across the fallthrough edge. Let me know which patch would be preferable, and I'll submit it.
[Bug c++/91993] [8/9/10 Regression] Spurious -Wconversion warning with -fsanitize=undefined since r6-4886-gcda0a029f45d20f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91993 --- Comment #4 from Jakub Jelinek --- Created attachment 47971 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47971&action=edit gcc10-pr91993-wip.patch As implemented in this completely untested (so far) patch, which makes the -Wconversion warning go away both in the case of comma operator with user side-effects as well as -fsanitize=undefined.
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #40 from Alexander Cherepanov ---
(In reply to Vincent Lefèvre from comment #35)
> > You seem to say that either Annex F is fully there or not at all but why?
> > -fno-signed-zeros breaks Annex F but only parts of it. Isn't it possible to
> > retain the other parts of it? Maybe it's impossible or maybe it's impossible
> > to retain division by zero, I don't know. What is your logic here?
>
> This issue is that the nice property x == y implies f(x) == f(y), in
> particular, x == y implies 1 / x == 1 / y is no longer valid with signed
> zeros. Thus one intent of -fno-signed-zeros could be to enable optimizations
> based on this property. But this means that division by zero becomes
> undefined behavior (like in C without Annex F). Major parts of Annex F would
> still remain valid.
I agree that the intent is to enable optimization based on the property "x == y
implies f(x) == f(y)". But I'm not sure what follows from this.
Sure, one possibility is make undefined any program that uses f(x) where x
could be a zero and f(x) differs for two zeros. But this approach make printf
and memory-accesss undefined too. Sorry, I don't how you could undefine
division by zero while not undefining printing of zero.
Another approach is to say that we don't care which of possible two values f(x)
returns x is zero. That is, we don't care whether 1/0. is +inf or -inf and we
don't care whether printf("%g", 0.) outputs 0 or -0.
> > This means that you cannot implement you own printf: if you analyze sign bit
> > of your value to decide whether you need to print '-', the sign of zero is
> > significant in your code.
>
> If you want to implement a printf that takes care of the sign of 0, you must
> not use -fno-signed-zeros.
So if I use ordinary printf from a libc with -fno-signed-zeros it's fine but if
I copy its implementation into my own program it's not fine?
> > IOW why do you think that printf is fine while "1 / x == 1 / 0." is not?
>
> printf is not supposed to trigger undefined behavior. Part of its output is
> unspecified, but that's all.
Why the same couldn't be said about division? Division by zero is not supposed
to trigger undefined behavior. Part of its result (the sign of infinit) is
unspecified, but that's all.
> > > * Memory analysis. Again, the sign does not matter, but for instance,
> > > reading an object twice as a byte sequence while the object has not been
> > > changed by the code must give the same result. I doubt that this is
> > > affected
> > > by optimization.
> >
> > Working with objects on byte level is often optimized too:
>
> Indeed, there could be invalid optimization... But I would have thought that
> in such a case, the same kind of issue could also occur without
> -fno-signed-zeros. Indeed, if x == y, then this does not mean that x and y
> have the same memory representation. Where does -fno-signed-zeros introduce
> a difference?
Right. But it's well known that x == y doesn't imply that x and y have the same
value. And the only such case is zeros of different signs (right?). So
compilers deal with this case in a special way. (E.g., the optimization `if (x
== C) use(x)` -> `if (x == C) use(C)` is normally done only for non-zero FP
constant `C`. -fno-signed-zeros changes this.)
The idea that one value could have different representations is not widely
distributed. I didn't manage to construct a testcase for this yesterday but I
succeeded today -- see pr94035 (affects clang too).
The next level -- the same value, the same representation, different meaning.
E.g., pointers of different provenance. But that's another story:-)
> Note: There's also the case of IEEE 754 decimal floating-point formats (such
> as _Decimal64), for instance, due to the "cohorts", where two identical
> values can have different memory representations. Is GCC always correct here?
I have used pseudo-denormals in long double (x86_fp80) for this so far. Are
decimal floating-point formats more interesting?
[Bug target/81288] [8/9/10 Regression] ICE on 32-bit BE powerpcspe w/ -misel -O2 (-O3, -Ofast, -Os)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81288 --- Comment #10 from Segher Boessenkool --- Works in GCC 9, as in, the target does not exist any more in GCC 9.
[Bug target/80700] [8 Regression] ICE: Bus error (on SPE target)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80700 Segher Boessenkool changed: What|Removed |Added Known to work||9.0 Summary|[8/9/10 Regression] ICE:|[8 Regression] ICE: Bus |Bus error (on SPE target) |error (on SPE target) --- Comment #11 from Segher Boessenkool --- The target has been removed in GCC 9.
[Bug fortran/94030] [8/9/10 Regression] ICE equivalence of an integer and an element of an array of size n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94030 Thomas Koenig changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|--- |8.5 Summary|ICE equivalence of an |[8/9/10 Regression] ICE |integer and an element of |equivalence of an integer |an array of size n |and an element of an array ||of size n --- Comment #2 from Thomas Koenig --- This should be rejected.
[Bug rtl-optimization/94037] New: Runtime varies 2x just by order of two int assignments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94037
Bug ID: 94037
Summary: Runtime varies 2x just by order of two int assignments
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ncm at cantrip dot org
Target Milestone: ---
(This report re-uses some code from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93165 but identifies an entirely
different problem.)
Given:
```
bool swap_if(bool c, int& a, int& b) {
int v[2] = { a, b };
#ifdef FAST /* 4.6s */
b = v[1-c], a = v[c];
#else /* SLOW, 9.8s */
a = v[c], b = v[!c];
#endif
return c;
}
int* partition(int* begin, int* end) {
int pivot = end[-1];
int* left = begin;
for (int* right = begin; right < end - 1; ++right) {
left += swap_if(*right <= pivot, *left, *right);
}
int tmp = *left; *left = end[-1], end[-1] = tmp;
return left;
}
void quicksort(int* begin, int* end) {
while (end - begin > 1) {
int* mid = partition(begin, end);
quicksort(begin, mid);
begin = mid + 1;
} }
static const int size = 100'000'000;
#include
#include
#include
int main(int, char**) {
int fd = ::open("1e8ints", O_RDONLY);
int perms = PROT_READ|PROT_WRITE;
int flags = MAP_PRIVATE|MAP_POPULATE|MAP_NORESERVE;
auto* a = (int*) ::mmap(nullptr, size * sizeof(int), perms, flags, fd, 0);
quicksort(a, a + size);
return a[0] == a[size - 1];
}
```
after
```
$ dd if=/dev/urandom of=1e8ints bs=100 count=400
```
The run time of the the program above, built "-O3 -march=skylake"
vs. "-DFAST -O3 -march=skylake", varies by 2x on Skylake, similarly
on Haswell. Both cases are almost equally fast on Clang, matching
G++'s fast version. The difference between "!c" and "1-c" in the
array index exacerbates the disparity.
Godbolt `` says, slow:
```
movl(%rax), %edx
movl(%rbx), %esi
movl%esi, 8(%rsp)
movl%edx, 12(%rsp)
cmpl%edx, %ecx
setge %sil
movzbl %sil, %esi
movl8(%rsp,%rsi,4), %esi
movl%esi, (%rbx)
setl%sil
movzbl %sil, %esi
movl8(%rsp,%rsi,4), %esi
movl%esi, (%rax)
```
and 2x as fast:
```
movl(%rax), %ecx
cmpl%ecx, %r8d
setge %dl
movzbl %dl, %edx
movl(%rbx), %esi
movl%esi, 8(%rsp)
movl%ecx, 12(%rsp)
movl%r9d, %esi
subl%edx, %esi
movslq %esi, %rsi
movl8(%rsp,%rsi,4), %esi
movl%esi, (%rax)
movslq %edx, %rdx
movl8(%rsp,%rdx,4), %edx
movl%edx, (%rbx)
cmpl%ecx, %r8d
```
Clang 9.0.0, -DFAST, for reference:
```
movl(%rcx), %r11d
xorl%edx, %edx
xorl%esi, %esi
cmpl%r8d, %r11d
setle %dl
setg%sil
movl(%rbx), %eax
movl%eax, (%rsp)
movl%r11d, 4(%rsp)
movl(%rsp,%rsi,4), %eax
movl%eax, (%rcx)
movl(%rsp,%rdx,4), %eax
movl%eax, (%rbx)
```
[Bug c++/94038] New: Compiling with -Wall causes function template to get needlessly instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038
Bug ID: 94038
Summary: Compiling with -Wall causes function template to get
needlessly instantiated
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
With GCC trunk:
$ cat sa.cc
template
constexpr int
foo()
{
static_assert(T(1) == 0);
return 0;
}
constexpr int
bar(int a)
{
return a;
}
static_assert(decltype(bar(foo())){} == 0);
$ g++ -fsyntax-only -O sa.cc
$ g++ -fsyntax-only -O -Wall sa.cc
sa.cc: In instantiation of ‘constexpr int foo() [with T = int]’:
sa.cc:15:36: required from here
sa.cc:5:22: error: static assertion failed
5 | static_assert(T(1) == 0);
| ~^~~~
This seems to be a regression from GCC 9.
[Bug libstdc++/93978] A snippet using views::join fails to compile with -O1, but succeeds with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93978 Patrick Palka changed: What|Removed |Added Depends on||94038 --- Comment #1 from Patrick Palka --- I think the underlying cause of this issue is PR c++/94038 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038 [Bug 94038] Compiling with -Wall causes function template body to get needlessly instantiated
[Bug c++/94038] Compiling with -Wall causes function template body to get needlessly instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- > This seems to be a regression from GCC 9. Are you sure? I see the same thing with GCC 6.
[Bug middle-end/94004] [8/9/10 Regression] missing -Walloca on calls to alloca due to -Wno-system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94004 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #6 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2020-03/msg00251.html
[Bug middle-end/92478] [8 Regression] ICE on strcpy referencing an element of a static local constant array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92478 Martin Sebor changed: What|Removed |Added Summary|[8 Regression] ICE: |[8 Regression] ICE on |Segmentation fault |strcpy referencing an ||element of a static local ||constant array --- Comment #5 from Martin Sebor --- (In reply to John X from comment #3) > Would the ICE in gcc-8 be fixed? The fix looks simple enough to me to backport to GCC 8.5.
[Bug c++/91678] [9 Regression] decltype returns wrong type under certain conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91678
--- Comment #10 from Marek Polacek ---
With this patch GCC 9 ICEs on:
$ ./cc1plus -quiet pr87768.C -std=gnu++2a -fconcepts
pr87768.C: In instantiation of ‘constexpr const bool c::f’:
pr87768.C:14:29: required from here
pr87768.C:9:29: internal compiler error: in tsubst_copy, at cp/pt.c:15833
9 | requires requires(d e) { e[0]; }
|~^
0xaaad12 tsubst_copy
/home/mpolacek/src/gcc9/gcc/cp/pt.c:15833
0xac0b50 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc9/gcc/cp/pt.c:19709
0xaba51d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc9/gcc/cp/pt.c:18434
0xab8707 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc9/gcc/cp/pt.c:17969
0x8c892b satisfy_expression_constraint
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2070
0x8c92ff satisfy_constraint_1
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2242
0x8c90c9 satisfy_parameterized_constraint
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2185
0x8c9388 satisfy_constraint_1
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2257
0x8c944d satisfy_constraint
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2294
0x8c9511 satisfy_associated_constraints
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2318
0x8c97ed constraints_satisfied_p(tree_node*)
/home/mpolacek/src/gcc9/gcc/cp/constraint.cc:2393
0x8454e3 add_function_candidate
/home/mpolacek/src/gcc9/gcc/cp/call.c:
0x851d96 add_candidates
/home/mpolacek/src/gcc9/gcc/cp/call.c:5754
0x84d828 build_op_call_1
/home/mpolacek/src/gcc9/gcc/cp/call.c:4712
0x84e172 build_op_call(tree_node*, vec**, int)
/home/mpolacek/src/gcc9/gcc/cp/call.c:4808
0xb0e895 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/mpolacek/src/gcc9/gcc/cp/semantics.c:2602
0xabdd43 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/mpolacek/src/gcc9/gcc/cp/pt.c:19195
0xab8707 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/mpolacek/src/gcc9/gcc/cp/pt.c:17969
0xaa9801 tsubst_init
/home/mpolacek/src/gcc9/gcc/cp/pt.c:15527
0xad2f31 regenerate_decl_from_template
/home/mpolacek/src/gcc9/gcc/cp/pt.c:24262
because tsubst_copy/NON_LVALUE_EXPR gets
NON_LVALUE_EXPR (e)>
Don't know if I should pursue this backport.
[Bug c++/36566] Cannot bind packed field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36566
--- Comment #13 from Rene Rahn ---
(In reply to Eric Gallager from comment #12)
> (In reply to Rene Rahn from comment #10)
> > I know this is quite old now. But can someone explain me why using `#pragma
> > pack(push, 1)` does work then? I couldn't find enough resources on that. The
> > only thing I found is, that it does literally the same. But wouldn't then
> > the references/pointers still not be valid?
> >
> > So if I change the code to:
> >
> > ```
> > #pragma pack(push, 1)
> > struct Squeeze
> > {
> > short s;
> > };
> > #pragma pack(pop)
> > ```
> >
> > Then it works on godbolt with gcc-trunk.
>
> There are several bugs open about inconsistencies between
> __attribute__((packed)) and #pragma pack; see for example: bug 93910, bug
> 92900, bug 68160, and bug 60972
Ah great. Thanks for pointing to this.
[Bug target/86801] Powerpcspe port (may) need updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86801 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #1 from Segher Boessenkool --- GCC 9 does not support powerpcspe.
[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 86801, which changed state. Bug 86801 Summary: Powerpcspe port (may) need updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86801 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug c++/94034] [10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034 Marek Polacek changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-04 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |10.0 Summary|Broken diagnostic: |[10 Regression] Broken |'result_decl' not supported |diagnostic: 'result_decl' |by dump_expr|not supported by dump_expr Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r10-5821-g10d2f801f472931137deae1714d5b690c1862037
[Bug c++/94038] Compiling with -Wall causes function template body to get needlessly instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038 --- Comment #2 from Patrick Palka --- (In reply to Marek Polacek from comment #1) > > This seems to be a regression from GCC 9. > > Are you sure? I see the same thing with GCC 6. Oops, you're right, it's not a regression.
[Bug analyzer/94028] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94028 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:4ac3eb5c5f157bea22b5ae34b0df254d729dac25 commit r10-7028-g4ac3eb5c5f157bea22b5ae34b0df254d729dac25 Author: David Malcolm Date: Wed Mar 4 12:10:34 2020 -0500 analyzer: add regression test for fixed ICE [PR94028] The C++ reproducer for PR analyzer/94028 generates a similar ICE to that of the Fortran reproducer for PR analyzer/93993 and, like it, was fixed by r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa. This patch adds the C++ reproducer as a regression test. gcc/testsuite/ChangeLog: PR analyzer/94028 * g++.dg/analyzer/pr94028.C: New test.
[Bug c++/94039] New: conditional operator fails to use proper overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94039
Bug ID: 94039
Summary: conditional operator fails to use proper overload
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: monstrefou at gmail dot com
Target Milestone: ---
I believe the following program should compile but I get the error
"operands to ?: have different types 'INT_WRAPPER' and 'std::nullptr_t'"
class INT_WRAPPER
{
public:
operator int*() { return m_int = nullptr; }
private:
int* m_int;
};
int main()
{
true ? INT_WRAPPER() : nullptr;
}
>From my understanding neither type can't be implicitly converted to the other
type "target" as described in 7.6.16 paragraph 4
So it should do use overload resolution as per 7.6.16 paragraph 4
and operator?:(int*, int*) should be an available overload as per 12.7
paragraph 28
So in conclusion I think it this code should compile and the result type of the
conditional operator should be in* in this case
[Bug analyzer/93993] ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93993 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:4ac3eb5c5f157bea22b5ae34b0df254d729dac25 commit r10-7028-g4ac3eb5c5f157bea22b5ae34b0df254d729dac25 Author: David Malcolm Date: Wed Mar 4 12:10:34 2020 -0500 analyzer: add regression test for fixed ICE [PR94028] The C++ reproducer for PR analyzer/94028 generates a similar ICE to that of the Fortran reproducer for PR analyzer/93993 and, like it, was fixed by r10-7023-g3d66e153b40ed000af30a9e569a05f34d5d576aa. This patch adds the C++ reproducer as a regression test. gcc/testsuite/ChangeLog: PR analyzer/94028 * g++.dg/analyzer/pr94028.C: New test.
[Bug target/86133] powerpc (-mcpu=8548) internal compiler error for double variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86133 Segher Boessenkool changed: What|Removed |Added Target Milestone|--- |8.5
[Bug target/85121] Assembler messages: Error: operand out of range (264 is not between 0 and 248)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85121 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/81628] Backport r250637 and r250638 to the powerpcspe* target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81628 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/71012] ICE: in expand_expr_real_2, at expr.c:9348 when compiling stress-ng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71012 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806 --- Comment #41 from joseph at codesourcery dot com --- On Wed, 4 Mar 2020, rguenther at suse dot de wrote: > We're actually careful about the sign of zero here when recording > requivalences for propagation. I don't see anything preventing > equivalence based propagation for decimal floats though. > Also not sure if actual FP formats are required to be always > normalized ... All finite DFP values that can be represented with fewer decimal digits than the maximum for the format, and where the least significant nonzero decimal digit has an exponent greater than the smallest possible for the format, have representations with more than one possible quantum exponent, which are not equivalent even though they compare equal, and thus comparing equal should not result in an equivalence being recorded. E.g. _Decimal32 has 7-digit precision. 1.0DF and 1.00DF are different members of the same cohort, with quantum exponents -1 and -2, and compare equal but are not equivalent. 1.01DF uses all 7 digits so is the unique member of its cohort, so it is valid to use 1.01DF in place of anything that compared equal to 1.01DF. 1E-101DF is the least positive subnormal value; as -101 is the lowest quantum exponent, anything with a nonzero digit in the 10^-101 place is the unique member of its cohort and so 1E-101DF can be used in place of anything that compared equal to 1E-101DF. This is a separate matter from noncanonical encodings of DFP values. A noncanonical encoding is a valid representation that *is* fully equivalent to some canonical encoding - but most operations are supposed to produce only canonically encoded results. If a cohort has only one member but there are noncanonical encodings of that member, a canonical encoding can replace a noncanonical one (in general it's not required to propagate noncanonical encodings, even when permitted), but not vice versa.
[Bug analyzer/94028] ICE: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786 with -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94028 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Fixed (see comment 2); regression test added (see comment 3); marking as resolved. Thanks for filing this.
[Bug target/37759] powerpc option -mabi=no-spe still generates SPE instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37759 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/87083] ICE in extract_insn, at recog.c:2305 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87083 Segher Boessenkool changed: What|Removed |Added Target Milestone|--- |8.5
[Bug target/85170] ICE: in final_scan_insn_1, at final.c:3139 (error: could not split insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85170 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/84302] ICE: Segmentation fault (in extract_insn) on SPE target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84302 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug target/49854] Clean up SPE/e500 option handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49854 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org Target Milestone|--- |8.5
[Bug tree-optimization/93986] [10 Regression] ICE in decompose, at wide-int.h:984 since r10-5451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93986 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:10591cfe6cac200e926a73f3b8065147ce84 commit r10-7030-g10591cfe6cac200e926a73f3b8065147ce84 Author: Martin Sebor Date: Wed Mar 4 15:14:49 2020 -0700 PR tree-optimization/93986 - ICE on mixed-precision wide_int arguments gcc/testsuite/ChangeLog: PR tree-optimization/93986 * gcc.dg/pr93986.c: New test. gcc/ChangeLog: PR tree-optimization/93986 * tree-ssa-strlen.c (maybe_warn_overflow): Convert all wide_int operands to the same precision widest_int to avoid ICEs.
[Bug tree-optimization/93986] [10 Regression] ICE in decompose, at wide-int.h:984 since r10-5451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93986 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed.
[Bug c++/90432] [9/10 Regression] Internal compiler error with no_unique_address empty type with constructor call followed by value initialized to non-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90432 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6876b269bc7fe6465fedfed87c31e6175992129f commit r10-7031-g6876b269bc7fe6465fedfed87c31e6175992129f Author: Jason Merrill Date: Wed Mar 4 12:08:42 2020 -0500 c++: Fix [[no_unique_address]] and default mem-init [PR90432] output_constructor doesn't like two consecutive entries with fields at the same position; let's avoid adding the one for the empty field. gcc/cp/ChangeLog 2020-03-04 Jason Merrill PR c++/90432 * init.c (perform_member_init): Don't do aggregate initialization of empty field. * constexpr.c (cx_check_missing_mem_inits): Don't enforce initialization of empty field.
[Bug c++/90432] [9/10 Regression] Internal compiler error with no_unique_address empty type with constructor call followed by value initialized to non-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90432 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:9af9e004831f8efdfb68c2affea07b17fadd3279 commit r9-8332-g9af9e004831f8efdfb68c2affea07b17fadd3279 Author: Jason Merrill Date: Wed Mar 4 17:30:58 2020 -0500 c++: Fix [[no_unique_address]] and default mem-init [PR90432] output_constructor doesn't like two consecutive entries with fields at the same position; let's avoid adding the one for the empty field. gcc/cp/ChangeLog 2020-03-04 Jason Merrill PR c++/90432 * init.c (perform_member_init): Don't do aggregate initialization of empty field. * constexpr.c (cx_check_missing_mem_inits): Don't enforce initialization of empty field.
[Bug c++/90997] [9 Regression] ICE on a memset in a template in tsubst_copy_and_build, at cp/pt.c:18480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90997 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:831d4a690053599d2d0aa9713642b8513fdf8f5b commit r9-8331-g831d4a690053599d2d0aa9713642b8513fdf8f5b Author: Jason Merrill Date: Wed Mar 4 17:30:58 2020 -0500 c++: avoid ICE with __builtin_memset (PR90997). warn_for_memset calls fold_for_warn, which calls fold_non_dependent_expr, so also calling instantiate_non_dependent_expr here is undesirable. gcc/cp/ChangeLog 2020-03-04 Jason Merrill PR c++/90997 * semantics.c (finish_call_expr): Don't call instantiate_non_dependent_expr before warn_for_memset.
