[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315 --- Comment #11 from Richard Biener --- (In reply to Andrew Macleod from comment #10) > OK, so whats the deal here. I can't really follow what the final request, or > action is. > > Is there a conclusion on what needs to be done? if anything? See the original description - the request was to derive ranges for the offset operand in pointer arithmetic based on the size of the object offsetted. In the simple example a plain 'int' which is (in GIMPLE) offsetted by 4 * (a + b) where we should derive that a + b is zero.
[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535 --- Comment #12 from Jan Hubicka --- With ODR name hashing fix and fix to streaming the access types we now get: 957 false returned: 'different references' in compare_symbol_references at ../../gcc/ipa-icf.c:465 961 false returned: 'size mismatch' in equals_wpa at ../../gcc/ipa-icf.c:1651 1171 false returned: 'DECL_CXX_CONSTRUCTOR mismatch' in equals_wpa at ../../gcc/ipa-icf.c:562 1360 false returned: '' in compare_gimple_call at ../../gcc/ipa-icf-gimple.c:607 2209 false returned: 'different decl attributes' in equals_wpa at ../../gcc/ipa-icf.c:662 3362 false returned: 'ctor polymorphic type mismatch' in equals_wpa at ../../gcc/ipa-icf.c:585 8399 false returned: 'parameter type is not compatible' in compatible_parm_types_p at ../../gcc/ipa-icf.c:512 10161 false returned: 'inline attributes are different' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:350 16217 false returned: 'parameter types are not compatible' in equals_wpa at ../../gcc/ipa-icf.c:639 26071 false returned: 'references to virtual tables cannot be merged' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:373 28812 false returned: 'decl_or_type flags are different' in equals_wpa at ../../gcc/ipa-icf.c:572 29308 false returned: 'different tree types' in compatible_types_p at ../../gcc/ipa-icf-gimple.c:206 99308 false returned: 'types are not compatible' in compatible_types_p at ../../gcc/ipa-icf-gimple.c:212 119994 false returned: 'result types are different' in equals_wpa at ../../gcc/ipa-icf.c:621 128276 false returned: 'compare_ao_refs failed (semantic difference)' in compare_operand at ../../gcc/ipa-icf-gimple.c:336 242454 false returned: 'operand_equal_p failed' in compare_operand at ../../gcc/ipa-icf-gimple.c:356 369360 false returned: 'GIMPLE assignment operands are different' in compare_gimple_assign at ../../gcc/ipa-icf-gimple.c:699 370952 false returned: '' in equals_private at ../../gcc/ipa-icf.c:886 456907 false returned: 'THIS pointer ODR type mismatch' in equals_wpa at ../../gcc/ipa-icf.c:677 460246 false returned: 'types are not same for ODR' in compatible_polymorphic_types_p at ../../gcc/ipa-icf-gimple.c:197 so ODR types of THIS pointers come next.
[Bug c/97884] INT_MIN falsely expanded to 64 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884 --- Comment #1 from s.baur...@tu-berlin.de --- Created attachment 49584 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49584&action=edit preprocessed source
[Bug c/97884] New: INT_MIN falsely expanded to 64 bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
Bug ID: 97884
Summary: INT_MIN falsely expanded to 64 bit
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: s.baur...@tu-berlin.de
Target Milestone: ---
Created attachment 49583
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49583&action=edit
example file
arm-none-eabi-gcc: when compiling
printf("%i\n", -2147483648);
printf("%i\n", (int)-2147483648);
INT_MIN in the first call gets recognized as a 64 bit argument and split across
r2 and r3. r1 remains untouched. In the second call, INT_MIN is correctly put
into r1:
8: e3a02102mov r2, #-2147483648; 0x8000
c: e3e03000mvn r3, #0
10: e59f0010ldr r0, [pc, #16] ; 28
14: ebfebl 0
18: e3a01102mov r1, #-2147483648; 0x8000
1c: e59f0004ldr r0, [pc, #4]; 28
20: ebfebl 0
Source file attached was compiled with
arm-none-eabi-gcc -v -save-temps -c start.c -o start.o
gcc 10.2.0 was configured with
--target=arm-none-eabi --prefix=$(PREFIX) --enable-interwork
--enable-languages="c" --with-newlib --without-headers --disable-nls
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #39 from Levy ---
Checked all pass from 250r.shorten_memrefs to 270r.ce2
In 269r.combine I saw the following combination merged the replaced address:
---
modifying insn i327: r92:DI=r96:DI+0x300
REG_DEAD r96:DI
deferring rescan insn with uid = 27.
(!)allowing combination of insns 27 and 6
original costs 4 + 16 = 20
replacement costs 4 + 16 = 20
modifying insn i227: r92:DI=r96:DI+0x300
deferring rescan insn with uid = 27.
modifying insn i3 6: r82:DI=sign_extend([r96:DI+0x320])
REG_DEAD r96:DI
deferring rescan insn with uid = 6.
(!)allowing combination of insns 27 and 8
original costs 4 + 16 = 20
replacement costs 4 + 16 = 20
modifying insn i227: r92:DI=r96:DI+0x300
deferring rescan insn with uid = 27.
modifying insn i3 8: r84:DI=sign_extend([r96:DI+0x324])
REG_DEAD r96:DI
deferring rescan insn with uid = 8.
(!)allowing combination of insns 27 and 12
original costs 4 + 16 = 20
replacement costs 4 + 16 = 20
modifying insn i227: r92:DI=r96:DI+0x300
deferring rescan insn with uid = 27.
modifying insn i312: r87:DI=sign_extend([r96:DI+0x328])
REG_DEAD r96:DI
deferring rescan insn with uid = 12.
(!)allowing combination of insns 27 and 16
original costs 4 + 16 = 20
replacement cost 16
deferring deletion of insn with uid = 27.
modifying insn i316: r90:DI=sign_extend([r96:DI+0x32c])
REG_DEAD r96:DI
deferring rescan insn with uid = 16.
allowing combination of insns 18 and 19
---
Where in 268r.ud_dce both insns 27 are same (except for memory address):
(insn 27 26 28 2 (set (reg:DI 10 a0)
(lo_sum:DI (reg/f:DI 85)
(symbol_ref/f:DI ("*.LC0") [flags 0x82] ))) "array_test.c":21:5 133 {*lowdi}
(expr_list:REG_DEAD (reg/f:DI 85)
(expr_list:REG_EQUAL (symbol_ref/f:DI ("*.LC0") [flags 0x82] )
(nil
---
In 270r.combine (patched):
(note 27 3 6 2 NOTE_INSN_DELETED)
and following insns 768 + 32/36/40/44 were put back as:
(insn 6 27 8 2 (set (reg:DI 82 [ MEM[(int *)array_5(D) + 800B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 800 [0x320])) [1 MEM[(int *)array_5(D) + 800B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(insn 8 6 10 2 (set (reg:DI 84 [ MEM[(int *)array_5(D) + 804B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 804 [0x324])) [1 MEM[(int *)array_5(D) + 804B]+0
S4 A32]))) "array_test.c":7:5 90 {extendsidi2}
(insn 12 10 14 2 (set (reg:DI 87 [ MEM[(int *)array_5(D) + 808B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 808 [0x328])) [1 MEM[(int *)array_5(D) + 808B]+0
S4 A32]))) "array_test.c":8:5 90 {extendsidi2}
(insn 16 14 18 2 (set (reg:DI 90 [ MEM[(int *)array_5(D) + 812B] ])
(sign_extend:DI (mem:SI (plus:DI (reg:DI 96)
(const_int 812 [0x32c])) [1 MEM[(int *)array_5(D) + 812B]+0
S4 A32]))) "array_test.c":9:5 90 {extendsidi2}
(expr_list:REG_DEAD (reg:DI 96)
(nil)))
Maybe combine.c needs some modification?
[Bug target/97873] Failure to optimize abs optimally (at least one completely useless instruction on x86)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97873 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #3 from Hongtao.liu --- > > where the smax:SI is late splitted IIRC. That's probably not the optimal > expansion choice. > > I remember a duplicate bug. PR92651？ we introduce (define_expand "abs2" [(set (match_operand:SWI48x 0 "register_operand") (abs:SWI48x (match_operand:SWI48x 1 "register_operand")))] "TARGET_EXPAND_ABS" Compile with -O2 -march=corei7 got abs(int): movl%edi, %eax cltd xorl%edx, %eax subl%edx, %eax ret
[Bug demangler/85304] Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85304 Nikhil changed: What|Removed |Added CC||nmahalle at in dot ibm.com --- Comment #5 from Nikhil --- Hi, May I know whether this bug is fixed? And if fixed, in which version of binutils this fix has gone? Any heads up will be appreciated. Thanks in advance. Best Regards,
[Bug c++/97883] New: [C++20] Segmentation fault on template with braced initializer list A<{}>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97883
Bug ID: 97883
Summary: [C++20] Segmentation fault on template with
braced initializer list A<{}>
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/841ahx
template struct A;
A<{}> a;
In -std=c++17 mode, this gives an error as expected. In -std=c++20 mode, this
segfaults:
:2:5: error: deducing from brace-enclosed initializer list requires
'#include '
+++ |+#include
1 | template struct A;
2 | A<{}> a;
| ^
:2:5: internal compiler error: Segmentation fault
0x1bf9b89 internal_error(char const*, ...)
???:0
0x8a5846 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
???:0
0x8c48ac lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0x9197cd finish_template_type(tree_node*, tree_node*, int)
???:0
0x87f57c c_parse_file()
???:0
0x9f7452 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/97744] [11 regression] 32 bit floating point result errors after r11-4637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97744 Kewen Lin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #6 from Kewen Lin --- With the above findings, I think the culprit commit just gets the fragile tolerance issue exposed again, closed as invalid.
[Bug tree-optimization/91029] missed optimization regarding value of modulo operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029 --- Comment #5 from Bruno Haible --- Nice! Thank you.
[Bug libstdc++/93421] futex.cc use of futex syscall is not time64-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421 --- Comment #10 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1e3e6c700f04fe6992b9077541e434172c1cbdae commit r11-5114-g1e3e6c700f04fe6992b9077541e434172c1cbdae Author: Jonathan Wakely Date: Tue Nov 17 16:13:02 2020 + libstdc++: Revert changes for SYS_clock_gettime64 [PR 93421] As discussed in the PR, it's incredibly unlikely that a system that needs to use the SYS_clock_gettime syscall (e.g. glibc 2.16 or older) is going to define the SYS_clock_gettime64 macro. Ancient systems that need to use the syscall aren't going to have time64 support. This reverts the recent changes to try and make clock_gettime syscalls be compatible with systems that have been updated for time64 (those changes were wrong anyway as they misspelled the SYS_clock_gettime64 macro). The changes for futex syscalls are retained, because we still use them on modern systems that might be using time64. To ensure that the clock_gettime syscalls are safe, configure will fail if SYS_clock_gettime is needed, and SYS_clock_gettime64 is also defined (but to a distinct value from SYS_clock_gettime), and the tv_sec member of timespec is larger than long. This means we will be unable to build on a hypothetical system where we need the time32 version of SYS_clock_gettime but where userspace is using a time64 struct timespec. In the unlikely event that this failure is triggered on any real systems, we can fix it later. But we probably won't need to. libstdc++-v3/ChangeLog: PR libstdc++/93421 * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Fail if struct timespec isn't compatible with SYS_clock_gettime. * configure: Regenerate. * src/c++11/chrono.cc: Revert changes for time64 compatibility. Add static_assert instead. * src/c++11/futex.cc (_M_futex_wait_until_steady): Assume SYS_clock_gettime can use struct timespec.
[Bug tree-optimization/91191] vrp and boolean arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191 Andrew Macleod changed: What|Removed |Added CC||aldyh at redhat dot com, ||jason at redhat dot com, ||law at redhat dot com --- Comment #4 from Andrew Macleod --- Its unclear to me what should be done here. the documentation for VIEW_CONVERT is quite clear in tree.def: "The only operand is the value to be viewed as being of another type. It is undefined if the type of the input and of the expression have different sizes." I realized range-ops isn't currently doing anything with VIEW_CONVERT, but when I tried changing this test case to similar precisions, the VIEW_CONVERT goes away. My knowledge of VIEW_CONVERT is, well, poor to non-existent. so 1) Why are we issuing a VIEW_CONVERT in the first place? They are different precision's and this appears to break the very definition 2) when they are the same precision, there wouldn't need to be a sign extension, so how does it vary from a cast? 1) and 2) seem incongruent to me. Either you confirm they are the same size and do a cast, or they are different precisions and you want to avoid the normal cast behaviour. Or has this got something to do with a difference in precision but understanding the the underlying storage is actually the same size? So we only issue a VIEW_CONVERT when precision is different but storage is the same size? so you can make certain assumption about the value? but that seem wrought with issues too...
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 Bug 85316 depends on bug 91029, which changed state. Bug 91029 Summary: missed optimization regarding value of modulo operation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/91029] missed optimization regarding value of modulo operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Macleod --- I adjusted range-ops to properly calculate those ranges for 'a' in LHS = a % b when LHS and b match what was described. I also added a test case that confirms the conditions are tracked and branches folded.
[Bug c/97882] [8/9/10/11 Regression] Segmentation Fault on improper redeclaration of function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97882
Joseph S. Myers changed:
What|Removed |Added
Last reconfirmed||2020-11-17
Target Milestone|--- |8.5
Status|UNCONFIRMED |NEW
Summary|Segmentation Fault on |[8/9/10/11 Regression]
|improper redeclaration of |Segmentation Fault on
|function|improper redeclaration of
||function
Ever confirmed|0 |1
--- Comment #1 from Joseph S. Myers ---
Looks like a regression in GCC 7 relative to GCC 6. Whether this code is valid
or invalid GNU C is a tricky question, but I'm inclined to say that when the
incomplete enum type extension is used, we should *not* count such enums as
compatible with unsigned int since we don't know what members the enum will
have once completed. So, for example, I think we ought to reject
extern enum foo *x;
unsigned int *x;
and certainly ought to reject
extern enum foo *x;
unsigned int *x;
enum foo { A = -1 };
where the enum ends up compatible with int rather than unsigned int. (But a
patch involving rejecting such code might not be such a good idea for
backporting, given the risk of breaking user programs that build OK with the
release branch compilers.)
(A C11 defect fix incorporated in C17 means a qualifier on a function return
type is ignored, so whether the code is valid is not affected by the "const" in
the original test case.)
[Bug libstdc++/94936] pmr::synchronized_pool_resource crashes without -pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94936 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- Fixed
[Bug libstdc++/94936] pmr::synchronized_pool_resource crashes without -pthread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94936 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:cbc9dab25fb807278d2e09ec3e89e466385c9fce commit r9-9054-gcbc9dab25fb807278d2e09ec3e89e466385c9fce Author: Jonathan Wakely Date: Mon May 4 13:34:23 2020 +0100 libstdc++: Make pmr::synchronized_pool_resource work without libpthread (PR 94936) I implicitly assumed that programs using pmr::synchronized_pool_resource would also be using multiple threads, and so the weak symbols in gthr-posix.h would be resolved by linking to libpthread. If that isn't true then it crashes when trying to use pthread_key_create. This commit makes the pool resource check __gthread_active_p() before using thread-specific data, and just use a single set of memory pools when there's only a single thread. PR libstdc++/94936 * src/c++17/memory_resource.cc (synchronized_pool_resource::_TPools): Add comment about single-threaded behaviour. (synchronized_pool_resource::_TPools::move_nonempty_chunks()): Hoist class member access out of loop. (synchronized_pool_resource::synchronized_pool_resource()) (synchronized_pool_resource::~synchronized_pool_resource()) (synchronized_pool_resource::release()): Check __gthread_active_p before creating and/or deleting the thread-specific data key. (synchronized_pool_resource::_M_thread_specific_pools()): Adjust assertions. (synchronized_pool_resource::do_allocate(size_t, size_t)): Add fast path for single-threaded case. (synchronized_pool_resource::do_deallocate(void*, size_t, size_t)): Likewise. Return if unable to find a pool that owns the allocation. * testsuite/20_util/synchronized_pool_resource/allocate_single.cc: New test. * testsuite/20_util/synchronized_pool_resource/cons_single.cc: New test. * testsuite/20_util/synchronized_pool_resource/release_single.cc: New test. (cherry picked from commit ec40967f1323069da3a5a45286f71fa4f80926df)
[Bug target/97865] libtool needs to be updated for Darwin20.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #13 from Iain Sandoe --- (In reply to jos...@codesourcery.com from comment #12) > config.sub and config.guess are imported, unmodified, from upstream > config.git. thanks I will try to do that and test it over the next days (I've been using a newish version on arm64-darwin20 for a few months so don't anticipate problems - but who knows). > libtool has lots of local changes, hopefully all of them submitted > upstream but maybe not and maybe some not committed upstream (libtool has > very few commits in recent years, but lots since the 2009 version used in > GCC). As well as checking all the local changes (relative to libtool > commit 2c9c38d8a12eb0a2ce7fe9c3862523026c3d5622, apparently) and applying > them to a new version as needed, updating libtool would also require > reverting libtool commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c to deal > with a mismatch of --with-sysroot interpretations. The patch I have here is a additional local change (and specific to Darwin), unfortunately, I don't have resources to address the scope of work you describe.
[Bug target/97865] libtool needs to be updated for Darwin20.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #12 from joseph at codesourcery dot com --- config.sub and config.guess are imported, unmodified, from upstream config.git. libtool has lots of local changes, hopefully all of them submitted upstream but maybe not and maybe some not committed upstream (libtool has very few commits in recent years, but lots since the 2009 version used in GCC). As well as checking all the local changes (relative to libtool commit 2c9c38d8a12eb0a2ce7fe9c3862523026c3d5622, apparently) and applying them to a new version as needed, updating libtool would also require reverting libtool commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c to deal with a mismatch of --with-sysroot interpretations.
[Bug tree-optimization/91029] missed optimization regarding value of modulo operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029 --- Comment #3 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:1e27e7a582a9b86bcf86f5c103cd947672746e97 commit r11-5111-g1e27e7a582a9b86bcf86f5c103cd947672746e97 Author: Andrew MacLeod Date: Tue Nov 17 14:47:58 2020 -0500 recognize implied ranges for modulo. implement op1_range for modulo with implied positive and negative ranges. gcc/ PR tree-optimization/91029 * range-op.cc (operator_trunc_mod::op1_range): New. gcc/testsuite/ * gcc.dg/pr91029.c: New.
[Bug tree-optimization/22326] promotions (from float to double) are not removed when they should be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326 --- Comment #7 from joseph at codesourcery dot com --- I agree that match.pd is a sensible place for this (and the front end is not, we should be getting optimizations out of the front ends). I'd encourage anyone looking at this also to look at convert_to_real_1, which has different, related optimizations (which also would be better off in match.pd rather than as part of convert). The particular example test in this bug report would also need to pass that deals with fusing operations (when permitted by the fp-contract setting) to handle the case where promotions to a wider type (with the same radix) are involved; I don't know if it does handle that at present.
[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535 --- Comment #11 from Jan Hubicka --- Created attachment 49582 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49582&action=edit Memory use of GCC 10 release branch with ICF
[Bug c++/97877] [11 Regression] ICE in cp_genericize_r, at cp/cp-gimplify.c:968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97877 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Nathan Sidwell --- Fixed e0da4aed176
[Bug c++/97877] [11 Regression] ICE in cp_genericize_r, at cp/cp-gimplify.c:968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97877 --- Comment #3 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:e0da4aed176a8de042a8482beb65499e29448556 commit r11-5108-ge0da4aed176a8de042a8482beb65499e29448556 Author: Nathan Sidwell Date: Tue Nov 17 13:16:47 2020 -0800 c++: duplicate block-scope extern [PR 97877] We ICED with a duplicated block-scope extern, as duplicate_decls was dropping the decl_lang_specific of olddecl. Simplys adding appropriate retrofitting and copying turned out to be insufficient because you can get a block-scope using decl also matching the extern. The latter seems a little suspicious and I have asked CWG for advice. While there robustified the assert about releasing olddecls' lang-specific -- if it had one, the new decl better have one. PR c++/97877 gcc/cp/ * decl.c (duplicate_decls): Deal with duplicated DECL_LOCAL_DECL_P decls. Extend decl_lang_specific checking assert. gcc/testsuite/ * g++.dg/lookup/pr97877.C: New.
[Bug target/97865] MACOSX_DEPLOY_TARGET needs to be updated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 --- Comment #11 from Iain Sandoe --- Created attachment 49581 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49581&action=edit regenerated files the second patch is all the regenerated files .. much larger :)
[Bug target/97865] MACOSX_DEPLOY_TARGET needs to be updated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865 Iain Sandoe changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #10 from Iain Sandoe --- Created attachment 49580 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49580&action=edit fix under test The patch (no doubt needs some polishing and a ChangeLog of course) makes the changes to remove the global setting of undefined, dynamic_lookup for Darwin. It adds this in specifically, where needed, in libcc1 and libitm. NOTE: this contains no regenerated files, I'll add those as a separate attachment. Because the regenerated files are across the whole of the source tree, etc. this needs wide testing - initial results are encouraging tho.
[Bug c/97882] New: Segmentation Fault on improper redeclaration of function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97882
Bug ID: 97882
Summary: Segmentation Fault on improper redeclaration of
function
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jarod.keene at trojans dot dsu.edu
Target Milestone: ---
Created attachment 49579
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49579&action=edit
Save Temps output from code compilation
After fuzzing GCC version 10.2.0 for grammar-based errors we discovered a
segmentation fault flaw within the compiler. This flaw is also none to be
present in GCC versions 7.5.0, 8.3.0, and 9.3.0. Attached is the output from
-save-temps.
GCC Compilation and system options:
Debian 5.8.0
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.0-16'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-YRn5ue/gcc-10-10.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-YRn5ue/gcc-10-10.2.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=yes,extra,rtl --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Compilation Command Line: gcc bug.c
Compilation Error Message:
bug.c: In function ‘x’:
bug.c:4:2: internal compiler error: Segmentation fault
4 | const unsigned x() {};
| ^
0xfe8a6f crash_signal
../../src/gcc/toplev.c:328
0x7f65d0b7ce2f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xb01de6 must_pass_in_stack_var_size_or_pad(function_arg_info const&)
../../src/gcc/calls.c:6216
0x130b3e8 ix86_must_pass_in_stack
../../src/gcc/config/i386/i386.c:1458
0x1337b4a classify_argument
../../src/gcc/config/i386/i386.c:2065
0x13383ca examine_argument
../../src/gcc/config/i386/i386.c:2459
0x1338d31 ix86_return_in_memory
../../src/gcc/config/i386/i386.c:3826
0xca98fe aggregate_value_p(tree_node const*, tree_node const*)
../../src/gcc/function.c:2111
0xcae74c allocate_struct_function(tree_node*, bool)
../../src/gcc/function.c:4814
0x9e9774 store_parm_decls()
../../src/gcc/c/c-decl.c:9781
0xa42092 c_parser_declaration_or_fndef
../../src/gcc/c/c-parser.c:2466
0xa21fff c_parser_compound_statement_nostart
../../src/gcc/c/c-parser.c:5718
0xa40764 c_parser_compound_statement
../../src/gcc/c/c-parser.c:5617
0xa42221 c_parser_declaration_or_fndef
../../src/gcc/c/c-parser.c:2505
0xa4a393 c_parser_external_declaration
../../src/gcc/c/c-parser.c:1745
0xa4ae91 c_parser_translation_unit
../../src/gcc/c/c-parser.c:1618
0xa4ae91 c_parse_file()
../../src/gcc/c/c-parser.c:21752
0xaa219b c_common_parse_file()
../../src/gcc/c-family/c-opts.c:1190
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 --- Comment #3 from Eric Niebler --- It seems like GitHub actions uses the latest libstdc++ by default when testing even with old (e.g., clang-4) toolsets. That seems busted, but regardless, this is now breaking _all_ my Linux clang tests for anything less than clang-9, which is unfortunate.
[Bug target/97870] [11 Regression] ICE: verify_flow_info failed (error: too many outgoing branch edges from bb 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97870 --- Comment #2 from Vladimir Makarov --- (In reply to Richard Biener from comment #1) > Possibly related to the asm goto enhancements. This test should work only for x86-64. Running it on other targets can give an error. So error about inconsistent operand constraints is ok. What is wrong is an internal compiler error. The problem is in deleting wrong asm goto in LRA which results in wrong CFG. I've started work on this PR. The fix will be ready this week.
[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535 --- Comment #10 from Jan Hubicka --- Here are main reason for miscompares: 1125 libxul.so.wpa.076i.icf: false returned: 'variables types are different' in equals at ../../gcc/ipa-icf.c:1697 1171 libxul.so.wpa.076i.icf: false returned: 'DECL_CXX_CONSTRUCTOR mismatch' in equals_wpa at ../../gcc/ipa-icf.c:562 2211 libxul.so.wpa.076i.icf: false returned: 'different decl attributes' in equals_wpa at ../../gcc/ipa-icf.c:662 3362 libxul.so.wpa.076i.icf: false returned: 'ctor polymorphic type mismatch' in equals_wpa at ../../gcc/ipa-icf.c:585 3627 libxul.so.wpa.076i.icf: false returned: 'GIMPLE LHS type mismatch' in compare_gimple_assign at ../../gcc/ipa-icf-gimple.c:695 5297 libxul.so.wpa.076i.icf: false returned: '' in compare_decl at ../../gcc/ipa-icf-gimple.c:157 5304 libxul.so.wpa.076i.icf: false returned: '' in compare_variable_decl at ../../gcc/ipa-icf-gimple.c:422 5304 libxul.so.wpa.076i.icf: false returned: '' in operand_equal_p at ../../gcc/ipa-icf-gimple.c:291 8588 libxul.so.wpa.076i.icf: false returned: 'parameter type is not compatible' in compatible_parm_types_p at ../../gcc/ipa-icf.c:512 10188 libxul.so.wpa.076i.icf: false returned: 'inline attributes are different' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:350 16218 libxul.so.wpa.076i.icf: false returned: 'parameter types are not compatible' in equals_wpa at ../../gcc/ipa-icf.c:639 26076 libxul.so.wpa.076i.icf: false returned: 'references to virtual tables cannot be merged' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:373 28813 libxul.so.wpa.076i.icf: false returned: 'decl_or_type flags are different' in equals_wpa at ../../gcc/ipa-icf.c:572 32478 libxul.so.wpa.076i.icf: false returned: 'different tree types' in compatible_types_p at ../../gcc/ipa-icf-gimple.c:206 60520 libxul.so.wpa.076i.icf: false returned: 'call function types are not compatible' in compare_gimple_call at ../../gcc/ipa-icf-gimple.c:635 106399 libxul.so.wpa.076i.icf: false returned: 'types are not compatible' in compatible_types_p at ../../gcc/ipa-icf-gimple.c:212 120240 libxul.so.wpa.076i.icf: false returned: 'result types are different' in equals_wpa at ../../gcc/ipa-icf.c:621 269745 libxul.so.wpa.076i.icf: false returned: 'compare_ao_refs failed (semantic difference)' in compare_operand at ../../gcc/ipa-icf-gimple.c:336 355772 libxul.so.wpa.076i.icf: false returned: '' in compare_gimple_call at ../../gcc/ipa-icf-gimple.c:607 456913 libxul.so.wpa.076i.icf: false returned: 'THIS pointer ODR type mismatch' in equals_wpa at ../../gcc/ipa-icf.c:677 460252 libxul.so.wpa.076i.icf: false returned: 'types are not same for ODR' in compatible_polymorphic_types_p at ../../gcc/ipa-icf-gimple.c:197 1391954 libxul.so.wpa.076i.icf: false returned: 'GIMPLE assignment operands are different' in compare_gimple_assign at ../../gcc/ipa-icf-gimple.c:699 1477890 libxul.so.wpa.076i.icf: false returned: 'operand_equal_p failed' in compare_operand at ../../gcc/ipa-icf-gimple.c:356 1840986 libxul.so.wpa.076i.icf: false returned: '' in equals_private at ../../gcc/ipa-icf.c:886 So compare_ao_refs is not really a top even though it can be improved. I suppose it is time to improve the hash. Common problem is OBJ_TYPE_REF(_7;(struct nsServerSocket)_1->2) (_1); OBJ_TYPE_REF(_7;(struct nsJSProtocolHandler)_1->2) (_1); this happens 350645 (24% of the operand_equal_p failures) so I guess one can start from there. here clearly we want to hash ODR name of the OTR type.
[Bug target/97866] [11 Regression] bootstrap error in libasan building a s390x-linux-gnu cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97866 --- Comment #3 from Ilya Leoshkevich --- I believe it's already fixed by: commit 253c415a1acba50711c82693426391743ac18040 Author: Vladimir N. Makarov Date: Sun Nov 15 11:22:19 2020 -0500 Do not put reload insns in the last empty BB. gcc/ * lra.c (lra_process_new_insns): Don't put reload insns in the last empty BB. Cherry-picking it helps, and the comment from this commit describes what is happening here: "Do not put reload insns if it is the last BB without actual insns. In this case the reload insns can get null BB after emitting".
[Bug target/97866] [11 Regression] bootstrap error in libasan building a s390x-linux-gnu cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97866
--- Comment #2 from Ilya Leoshkevich ---
Never mind, I managed to reproduce it now:
ubuntu-focal-amd64$ git rev-parse --short HEAD
77f67db2a47
ubuntu-focal-amd64$ ../configure --target=s390x-linux-gnu --exec-prefix=/usr
--disable-bootstrap --disable-multilib --enable-languages=c,c++
ubuntu-focal-amd64$ cat test.cpp
typedef long a;
typedef void (*b)(a, a, void *);
class c {
unsigned char *m_fn1();
char d(a);
a e(a);
void f();
};
b g;
void *h;
void c::f() {
for (a j; j < 6; j++) {
unsigned char *flags = m_fn1();
for (a i, k; i < k; i++) {
if (flags)
continue;
int *ff = reinterpret_cast(d(i));
g(a(ff), e(j), h);
}
}
}
ubuntu-focal-amd64$ gcc/xgcc -Bgcc -std=gnu++14 -O2 -c test.cpp
during RTL pass: reload
test.cpp: In member function ‘void c::f()’:
test.cpp:21:1: internal compiler error: in get_insn_freq, at lra.c:1554
[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535 --- Comment #9 from Jan Hubicka --- Created attachment 49578 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49578&action=edit Memory use of GCC trunk (11) without ICF
[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535 --- Comment #8 from Jan Hubicka --- Created attachment 49577 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49577&action=edit Memory use of GCC trunk (11) with ICF
[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535 Jan Hubicka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #7 from Jan Hubicka --- With today trunk (after icf memory handling patches) I get VM SIZE FILE SIZE ++ GROWING++ +1.3% +1.21Mi .text +1.21Mi +1.3% +5.2% +440Ki .eh_frame +440Ki +5.2% +7.1% +126Ki .eh_frame_hdr +126Ki +7.1% +0.4% +74.8Ki .rodata+74.8Ki +0.4% +0.6% +61.0Ki .rela.dyn +61.0Ki +0.6% +0.4% +15.4Ki .data.rel.ro.local +15.4Ki +0.4% +1.1% +11.1Ki .data.rel.ro +11.1Ki +1.1% [ = ] 0 .symtab+2.55Ki +0.0% +0.0% +64 .data +64 +0.0% +0.0% +24 .rela.plt +24 +0.0% +0.0% +16 .plt +16 +0.0% +0.2% +12 .gcc_except_table +12 +0.2% +0.0% +8 .got.plt+8 +0.0% -- SHRINKING -- [ = ] 0 .strtab-29.6Ki -0.1% -0.0% -32 .bss 0 [ = ] -0.0% -8 .got-8 -0.0% -+-+-+-+-+-+-+ MIXED +-+-+-+-+-+-+- +17% +44 [Unmapped] -3.74Ki -90.8% +1.3% +1.92Mi TOTAL +1.89Mi +0.9% time report of WPA with ICF: ipa lto gimple in : 6.45 ( 4%) 2.65 ( 16%) 9.04 ( 5%) 810M ( 12%) ipa lto gimple out : 1.87 ( 1%) 0.80 ( 5%) 2.72 ( 1%) 0 ( 0%) ipa lto decl in: 18.63 ( 11%) 1.26 ( 7%) 20.02 ( 10%) 2682M ( 41%) ipa lto decl out : 4.64 ( 3%) 0.20 ( 1%) 4.84 ( 3%) 0 ( 0%) ipa icf: 17.58 ( 10%) 0.59 ( 4%) 18.22 ( 9%) 24M ( 0%) TOTAL : 176.22 16.82193.31 6617M compared to: ipa lto gimple in : 0.48 ( 0%) 0.11 ( 1%) 0.77 ( 1%) 2905k ( 0%) ipa lto gimple out : 1.01 ( 1%) 0.84 ( 8%) 1.84 ( 1%) 0 ( 0%) ipa lto decl in: 18.74 ( 14%) 1.31 ( 12%) 19.90 ( 13%) 2682M ( 47%) ipa lto decl out : 4.34 ( 3%) 0.47 ( 4%) 4.79 ( 3%) 0 ( 0%) TOTAL : 138.62 10.61149.39 5715M So still pretty bad.
[Bug c++/93083] copy deduction rejected when doing CTAD for NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93083
--- Comment #5 from Marek Polacek ---
Short test from Bug 97751:
template
struct use_as_nttp {};
template
struct has_nttp {};
template
using has_nttp_2 = has_nttp;
[Bug c++/93083] copy deduction rejected when doing CTAD for NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93083 Marek Polacek changed: What|Removed |Added CC||janpmoeller at gmx dot de --- Comment #4 from Marek Polacek --- *** Bug 97751 has been marked as a duplicate of this bug. ***
[Bug c++/97751] C++20 NTTP: class template argument deduction failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97751 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Marek Polacek --- Dup I think. *** This bug has been marked as a duplicate of bug 93083 ***
[Bug c++/97801] overload resolution ambiguity isn't detected when rvalue ref qualifier is involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97801 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-11-17 --- Comment #1 from Marek Polacek --- Confirmed. Not a (recent) regression.
[Bug c++/97837] ICE on requires with *this in destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97837 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-11-17 --- Comment #3 from Marek Polacek --- Confirmed. 97837.C: In instantiation of ‘S< >::~S() requires is_rvalue_reference<...auto...>(*(S< >*)this) [with = int]’: 97837.C:10:8: required from here 97837.C:7:40: internal compiler error: in tsubst_copy, at cp/pt.c:16450 7 | requires(std::is_rvalue_reference(*this)); |^~~~ 0xc8dd45 tsubst_copy /home/mpolacek/src/gcc/gcc/cp/pt.c:16450 0xca546b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/mpolacek/src/gcc/gcc/cp/pt.c:20535 0xc9fc00 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/mpolacek/src/gcc/gcc/cp/pt.c:19476 0xc9f9d6 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/mpolacek/src/gcc/gcc/cp/pt.c:19454 0xc88f3c tsubst_tree_list(tree_node*, tree_node*, int, tree_node*) /home/mpolacek/src/gcc/gcc/cp/pt.c:15217 0xca401d tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/mpolacek/src/gcc/gcc/cp/pt.c:20306 0xca00af tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/mpolacek/src/gcc/gcc/cp/pt.c:19532 0xc9d976 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) /home/mpolacek/src/gcc/gcc/cp/pt.c:18932 0xa4f3f8 satisfy_atom /home/mpolacek/src/gcc/gcc/cp/constraint.cc:2718 0xa4f738 satisfy_constraint_r /home/mpolacek/src/gcc/gcc/cp/constraint.cc:2781 0xa4f7b8 satisfy_constraint /home/mpolacek/src/gcc/gcc/cp/constraint.cc:2801 0xa4f85d satisfy_associated_constraints /home/mpolacek/src/gcc/gcc/cp/constraint.cc:2819 0xa4fc73 satisfy_declaration_constraints /home/mpolacek/src/gcc/gcc/cp/constraint.cc:2908 0xa4fe25 constraint_satisfaction_value /home/mpolacek/src/gcc/gcc/cp/constraint.cc:2950 0xa4ffca constraints_satisfied_p(tree_node*) /home/mpolacek/src/gcc/gcc/cp/constraint.cc:2987 0xb1644f mark_used(tree_node*, int) /home/mpolacek/src/gcc/gcc/cp/decl2.c:5592 0xb17102 mark_used(tree_node*) /home/mpolacek/src/gcc/gcc/cp/decl2.c:5726 0xad0236 register_dtor_fn(tree_node*) /home/mpolacek/src/gcc/gcc/cp/decl.c:8846 0xb0f69b one_static_initialization_or_destruction /home/mpolacek/src/gcc/gcc/cp/decl2.c:4042 0xb0fbe8 do_static_initialization_or_destruction /home/mpolacek/src/gcc/gcc/cp/decl2.c:4128
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876
--- Comment #2 from Jonathan Wakely ---
Changing the _Stop_state_ref default constructor to:
_Stop_state_ref() noexcept {}
allows it to compile. It shouldn't be needed, but I suppose since the
constructor is already non-trivial (due to the default member initializer that
is the cause of the error) we could do that.
[Bug libstdc++/97876] stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 --- Comment #1 from Jonathan Wakely --- It works fine in Clang 9.0.0 though. We've never really set a hard limit on how many old versions of Clang we support, but given that 9 and 10 (and trunk) work, I'm inclined to think that three versions seems enough for new C++20 features.
[Bug c++/97878] [9/10/11 Regression] ICE in cxx_eval_outermost_constant_expr, at cp/constexpr.c:6825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97878 Marek Polacek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Seems to have started with r244639.
[Bug target/97866] [11 Regression] bootstrap error in libasan building a s390x-linux-gnu cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97866 Ilya Leoshkevich changed: What|Removed |Added CC||iii at linux dot ibm.com --- Comment #1 from Ilya Leoshkevich --- Could you please share your configure flags? On x86_64 Ubuntu 20.04 the following worked fine: ../configure --target=s390x-linux-gnu --exec-prefix=/usr --disable-bootstrap --disable-multilib --enable-languages=c,c++
[Bug tree-optimization/86707] Missed optimization: optimizing set of if statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86707 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #2 from Andrew Macleod --- This should get taken care of when ranger tracks must-be-one bits. _1 = x_7(D) & 1; if (_1 == 0) goto ; [INV] else goto ; [INV] _1 : unsigned int [0, 1] 2->3 (T) _1 : unsigned int [0, 0] 2->3 (T) x_7(D) : unsigned int [0, 4294967294] 2->4 (F) _1 : unsigned int [1, 1] 2->4 (F) x_7(D) : unsigned int [1, +INF] <..> === BB 4 x_7(D) unsigned int [1, +INF] : _2 = x_7(D) & 3; if (_2 == 0) goto ; [INV] Ideally, taking edge 2->4 will instead produce something like: x_7(D) unsigned int [1, +INF], bits set 0x0001 This would come from operator_bitwise_and::op1_range() with the LHS being subsituted back from the edge: [1,1] = x_7 & 1 in order for that to be true, the mask will have to be must-be-one and then the calculation of _2 = x_7(D) & 3; would produce a non-zero range when operator_bitwise_and sees the must-be-one bit, and propagates it since that bit is in the mask. so we'd get something like: _2 = [1, 3] bits set 0x0001 which would then allow _2 == 0 to be folded as always false. Planned for next release. PR 83073 also touched on this, but not in as much detail nor with as good an exmaple.
[Bug c++/97749] ICE: Segmentation Fault on C++20 NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97749 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=95291 --- Comment #1 from Marek Polacek --- Most likely a dup of bug 95291.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 70489, which changed state. Bug 70489 Summary: ICE in cxx_eval_increment_expression initializing a VLA in a constexpr function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70489 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/16994] [meta-bug] VLA and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 Bug 16994 depends on bug 70489, which changed state. Bug 70489 Summary: ICE in cxx_eval_increment_expression initializing a VLA in a constexpr function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70489 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/70489] ICE in cxx_eval_increment_expression initializing a VLA in a constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70489 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- Fixed by r276563 in GCC 10.
[Bug tree-optimization/85375] possible missed optimisation / regression from 6.3 with while (__builtin_ffs(x) && x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85375 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #2 from Andrew Macleod --- This appears to be resolved?
[Bug c++/97881] [11 Regression] ICE in warn_about_ambiguous_parse, at cp/parser.c:20800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97881 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Last reconfirmed||2020-11-17 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Target Milestone|--- |11.0 --- Comment #1 from Marek Polacek --- Mine.
[Bug target/96191] aarch64 stack_protect_test canary leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:3ee527923b1ce92c6b16c587d072720a6c813c95 commit r8-10627-g3ee527923b1ce92c6b16c587d072720a6c813c95 Author: Richard Sandiford Date: Tue Nov 17 18:16:45 2020 + aarch64: Clear canary value after stack_protect_test [PR96191] The stack_protect_test patterns were leaving the canary value in the temporary register, meaning that it was often still in registers on return from the function. An attacker might therefore have been able to use it to defeat stack-smash protection for a later function. gcc/ PR target/96191 * config/aarch64/aarch64.md (stack_protect_test_): Set the CC register directly, instead of a GPR. Replace the original GPR destination with an extra scratch register. Zero out operand 3 after use. (stack_protect_test): Update accordingly. gcc/testsuite/ PR target/96191 * gcc.target/aarch64/stack-protector-1.c: New test. * gcc.target/aarch64/stack-protector-2.c: Likewise. (cherry picked from commit fe1a26429038d7cd17abc53f96a6f3e2639b605f)
[Bug c++/97881] New: [11 Regression] ICE in warn_about_ambiguous_parse, at cp/parser.c:20800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97881
Bug ID: 97881
Summary: [11 Regression] ICE in warn_about_ambiguous_parse, at
cp/parser.c:20800
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-11.0.0-alpha20201115 snapshot (g:c746fc40f4ec8cfc1092efd49d567751858d2099)
ICEs when compiling the following testcase, reduced from test/Sema/atomic-ops.c
from the clang 10.0.1 test suite:
void
cb ()
{
volatile _Atomic (int) a1;
}
% g++-11.0.0 -c s10c4xmn.c
s10c4xmn.c: In function 'void a1()':
s10c4xmn.c:4:24: internal compiler error: in warn_about_ambiguous_parse, at
cp/parser.c:20800
4 | volatile _Atomic (int) cb;
|^
0x663c63 warn_about_ambiguous_parse
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:20800
0x9fb8b9 cp_parser_init_declarator
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:21084
0x9d9676 cp_parser_simple_declaration
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:13943
0x9f654d cp_parser_declaration_statement
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:13342
0x9db49f cp_parser_statement
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:11588
0x9dc57d cp_parser_statement_seq_opt
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:11954
0x9dc658 cp_parser_compound_statement
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:11904
0x9f66c4 cp_parser_function_body
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:23551
0x9f66c4 cp_parser_ctor_initializer_opt_and_function_body
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:23602
0x9fb199 cp_parser_function_definition_after_declarator
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:29492
0x9fc529 cp_parser_function_definition_from_specifiers_and_declarator
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:29408
0x9fc529 cp_parser_init_declarator
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:21124
0x9d9676 cp_parser_simple_declaration
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:13943
0xa06564 cp_parser_declaration
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:13640
0xa06f19 cp_parser_translation_unit
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:4806
0xa06f19 c_parse_file()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/cp/parser.c:44595
0xb2aa0d c_common_parse_file()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201115/work/gcc-11-20201115/gcc/c-family/c-opts.c:1196
[Bug c++/97877] [11 Regression] ICE in cp_genericize_r, at cp/cp-gimplify.c:968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97877 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/97878] [9/10/11 Regression] ICE in cxx_eval_outermost_constant_expr, at cp/constexpr.c:6825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97878 Marek Polacek changed: What|Removed |Added Target Milestone|--- |8.5 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-11-17 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/97877] [11 Regression] ICE in cp_genericize_r, at cp/cp-gimplify.c:968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97877 --- Comment #2 from Marek Polacek --- We ICE because stmt's DECL_LANG_SPECIFIC is null: 965 /* Map block scope extern declarations to visible declarations with the 966 same name and type in outer scopes if any. */ 967 if (VAR_OR_FUNCTION_DECL_P (stmt) && DECL_LOCAL_DECL_P (stmt)) 968 if (tree alias = DECL_LOCAL_DECL_ALIAS (stmt))
[Bug c/97880] New: [9/10/11 Regression] ICE in emit_library_call_value_1, at calls.c:5298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97880
Bug ID: 97880
Summary: [9/10/11 Regression] ICE in emit_library_call_value_1,
at calls.c:5298
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
With option -ftrapv at -O0, down to version r7 :
$ cat z1.c
void f ()
{
#pragma acc parallel loop tile(2, 3)
for (int i = 0; i < 8; i++)
for (long j = 0; j < 8; j++);
}
$ gcc-6 -c z1.c -fopenacc -ftrapv -O0
$
$ gcc-11-20201115 -c z1.c -fopenacc
$ gcc-11-20201115 -c z1.c -fopenacc -ftrapv -O1
$
$ gcc-11-20201115 -c z1.c -fopenacc -ftrapv -O0
during RTL pass: expand
z1.c: In function 'f._omp_fn.0':
z1.c:3:11: internal compiler error: in emit_library_call_value_1, at
calls.c:5298
3 | #pragma acc parallel loop tile(2, 3)
| ^~~
0x7304a0 emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
machine_mode, int, std::pair*)
../../gcc/calls.c:5296
0xa3b4c8 emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, rtx_def*, machine_mode, rtx_def*, machine_mode)
../../gcc/rtl.h:4258
0xa3b4c8 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
../../gcc/optabs.c:1837
0x83bd01 expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int, bool)
../../gcc/expmed.c:3571
0x858a04 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.c:9175
0x74af02 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3816
0x74af02 expand_gimple_stmt
../../gcc/cfgexpand.c:3877
0x74fb37 expand_gimple_basic_block
../../gcc/cfgexpand.c:5918
0x75219e execute
../../gcc/cfgexpand.c:6602
[Bug c/97879] [11 Regression] ICE in from_mode_char, at attribs.h:298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97879 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- These cases are related, but originate in r10 (20191124) : $ cat z4.c __attribute__ ((__access__(1))) void f (); $ cat z5.c __attribute__ ((access(1, 2))) void f (); $ cat z6.c __attribute__ ((access(2., 3.))) void f (); $ gcc-11-20201115 -c z4.c z4.c:1:1: internal compiler error: Segmentation fault 1 | __attribute__ ((__access__(1))) void f (); | ^ 0xb3b52f crash_signal ../../gcc/toplev.c:330 0x6f7ade handle_access_attribute ../../gcc/c-family/c-attribs.c:4369 0x6299f1 decl_attributes(tree_node**, tree_node*, int, tree_node*) ../../gcc/attribs.c:724 0x641252 start_decl(c_declarator*, c_declspecs*, bool, tree_node*, unsigned int*) ../../gcc/c/c-decl.c:5188 0x688366 c_parser_declaration_or_fndef ../../gcc/c/c-parser.c:2306 0x690297 c_parser_external_declaration ../../gcc/c/c-parser.c:1777 0x690db9 c_parser_translation_unit ../../gcc/c/c-parser.c:1650 0x690db9 c_parse_file() ../../gcc/c/c-parser.c:21882 0x6dfb82 c_common_parse_file() ../../gcc/c-family/c-opts.c:1196
[Bug c++/97877] [11 Regression] ICE in cp_genericize_r, at cp/cp-gimplify.c:968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97877 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org, ||nathan at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |11.0 Last reconfirmed||2020-11-17 --- Comment #1 from Marek Polacek --- Started with r11-3699.
[Bug c/97879] New: [11 Regression] ICE in from_mode_char, at attribs.h:298
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97879
Bug ID: 97879
Summary: [11 Regression] ICE in from_mode_char, at
attribs.h:298
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
This changed too between 20200823 and 20201004 :
(all with release builts)
$ cat z1.c
__attribute__ ((__access__(" ", 1))) void f (int *);
void f (int *);
$ cat z2.c
__attribute__ ((access ("none", 1))) void f (char *);
void f (char *);
$ gcc-11-20200823 -c z1.c
$
$ gcc-11-20201115 -c z1.c
z1.c:2:1: internal compiler error: in from_mode_char, at attribs.h:298
2 | void f (int *);
| ^~~~
0x62a79a attr_access::from_mode_char(char)
../../gcc/attribs.h:298
0x62a79a init_attr_rdwr_indices(hash_map, attr_access> >*,
tree_node*)
../../gcc/attribs.c:2069
0x6feec2 warn_parm_array_mismatch(unsigned int, tree_node*, tree_node*)
../../gcc/c-family/c-warn.c:3345
0x68931f c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2346
0x690297 c_parser_external_declaration
../../gcc/c/c-parser.c:1777
0x690db9 c_parser_translation_unit
../../gcc/c/c-parser.c:1650
0x690db9 c_parse_file()
../../gcc/c/c-parser.c:21882
0x6dfb82 c_common_parse_file()
../../gcc/c-family/c-opts.c:1196
[Bug tree-optimization/85315] missed range optimisation opportunity for derefences where index must be 0 or otherwise constrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #10 from Andrew Macleod --- OK, so whats the deal here. I can't really follow what the final request, or action is. Is there a conclusion on what needs to be done? if anything?
[Bug c++/97878] New: [9/10/11 Regression] ICE in cxx_eval_outermost_constant_expr, at cp/constexpr.c:6825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97878
Bug ID: 97878
Summary: [9/10/11 Regression] ICE in
cxx_eval_outermost_constant_expr, at
cp/constexpr.c:6825
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to r7 :
$ cat z1.cc
extern int a[];
auto [b] {a};
$ g++-6 -c z1.cc
z1.cc:2:6: error: expected unqualified-id before '[' token
auto [b] {a};
^
$ g++-11-20201115 -c z1.cc
z1.cc:2:12: internal compiler error: in cxx_eval_outermost_constant_expr, at
cp/constexpr.c:6825
2 | auto [b] {a};
|^
0x67e549 cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:6824
0x680c0c maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/cp/constexpr.c:7093
0x7cec1c store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc/cp/typeck2.c:747
0x6c410d check_initializer
../../gcc/cp/decl.c:6909
0x6c552e cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:7827
0x72fde4 cp_parser_decomposition_declaration
../../gcc/cp/parser.c:14225
0x72fde4 cp_parser_simple_declaration
../../gcc/cp/parser.c:13867
0x75307a cp_parser_declaration
../../gcc/cp/parser.c:13640
0x75390a cp_parser_translation_unit
../../gcc/cp/parser.c:4806
0x75390a c_parse_file()
../../gcc/cp/parser.c:44595
0x81d252 c_common_parse_file()
../../gcc/c-family/c-opts.c:1196
[Bug c++/97877] New: [11 Regression] ICE in cp_genericize_r, at cp/cp-gimplify.c:968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97877
Bug ID: 97877
Summary: [11 Regression] ICE in cp_genericize_r, at
cp/cp-gimplify.c:968
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20201004 and 20201018 :
$ cat z1.cc
void f ()
{
extern int a;
extern int a;
a = 2;
}
$ g++-11-20201004 -c z1.cc
$
$ g++-11-20201115 -c z1.cc
z1.cc: In function 'void f()':
z1.cc:6:1: internal compiler error: Segmentation fault
6 | }
| ^
0xc727ef crash_signal
../../gcc/toplev.c:330
0x69951f cp_genericize_r
../../gcc/cp/cp-gimplify.c:968
0xeef755 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.c:12058
0xeefd2e walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.c:12394
0x69a37d cp_genericize_r
../../gcc/cp/cp-gimplify.c:1166
0xeef755 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.c:12058
0x698e58 cp_genericize_tree
../../gcc/cp/cp-gimplify.c:1579
0x698ff3 cp_genericize(tree_node*)
../../gcc/cp/cp-gimplify.c:1725
0x6c2127 finish_function(bool)
../../gcc/cp/decl.c:17229
0x74ccee cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:29495
0x74dbf3 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:29408
0x74dbf3 cp_parser_init_declarator
../../gcc/cp/parser.c:21124
0x72f42a cp_parser_simple_declaration
../../gcc/cp/parser.c:13943
0x75307a cp_parser_declaration
../../gcc/cp/parser.c:13640
0x75390a cp_parser_translation_unit
../../gcc/cp/parser.c:4806
0x75390a c_parse_file()
../../gcc/cp/parser.c:44595
0x81d252 c_common_parse_file()
../../gcc/c-family/c-opts.c:1196
[Bug target/96835] Constructor in offload template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96835
--- Comment #7 from Tobias Weinzierl ---
Adding a default constructor to the vector class still does not allow us to
create the object on the target:
#include
#define mydt double
#pragma omp declare target
struct vector {
vector() {};
vector(mydt x, mydt y);
mydt dot(vector o);
mydt v[2];
};
vector::vector(mydt x, mydt y) {
v[0]=x;
v[1]=y;
}
mydt vector::dot(vector o) { return v[0] * o.v[0] + v[1]*o.v[1]; }
#pragma omp end declare target
int main() {
mydt res;
vector v1(1,1);
vector v2(1,3);
#pragma omp target map(from:res)
{
vector v3;
res = v1.dot(v2);
}
std::cout << res << "\n";
}
However, if we replace the default constructor with a default clause, then we
ca finally create a vector on the GPU, too:
#pragma omp declare target
struct vector {
vector() = default;
[...]
[Bug target/96835] Constructor in offload template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96835
--- Comment #6 from Tobias Weinzierl ---
We've found some more stuff. This works:
#include
#define mydt double
#pragma omp declare target
struct vector {
vector(mydt x, mydt y);
mydt dot(vector o);
mydt v[2];
};
vector::vector(mydt x, mydt y) {
v[0]=x;
v[1]=y;
}
mydt vector::dot(vector o) { return v[0] * o.v[0] + v[1]*o.v[1]; }
#pragma omp end declare target
int main() {
mydt res;
vector v1(1,1);
vector v2(1,3);
#pragma omp target map(from:res)
{
res = v1.dot(v2);
}
std::cout << res << "\n";
}
As soon as you instantiate the vector within the target region, it does not
work anymore:
int main() {
mydt res;
#pragma omp target map(from:res)
{
vector v1(1,1);
vector v2(1,3);
res = v1.dot(v2);
}
std::cout << res << "\n";
}
[Bug libstdc++/97876] New: stop_token header doesn't compile on clang-8 with -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876 Bug ID: 97876 Summary: stop_token header doesn't compile on clang-8 with -std=c++20 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: eric.niebler at gmail dot com Target Milestone: --- Compiling header with clang-8 in C++20 mode results in this: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/condition_variable:50: /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/stop_token:404:7: error: default member initializer for '_M_ptr' needed within definition of enclosing class 'stop_token' outside of member functions _Stop_state_ref() = default; ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/stop_token:478:21: note: in evaluation of exception specification for 'std::stop_token::_Stop_state_ref::_Stop_state_ref' needed here _Stop_state_ref _M_state; ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/stop_token:58:5: note: in evaluation of exception specification for 'std::stop_token::stop_token' needed here stop_token() noexcept = default; ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/stop_token:475:22: note: default member initializer declared here _Stop_state_t* _M_ptr = nullptr; ^ 1 error generated.
[Bug tree-optimization/83073] Range for VR_VARYING | [1, 1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83073 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #4 from Andrew Macleod --- I added a patch to 83072 in which multi-range will now recognize there is no [0,0] in x|1. When we add bitmask tracking to ranger, it is in the work queue to track both must-be-zero and must-be-one bits, and integrate that knowledge with range queries. (so if (x == 20) would be known false after x = x | 1) Any additional input on what kind of other information could be attached here to this PR.
[Bug c++/97871] [11 Regression] ICE in cp_parser_declaration, at cp/parser.c:13539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97871 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Sandoe --- so fixed.
[Bug tree-optimization/83072] Late VRP optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83072 --- Comment #8 from Andrew Macleod --- I've adjusted range-ops so that EVRP will recognize that c |= 1 is a non-zero range, and I've added a test case to check it. The rest of this PR involves exposing ranges in a better way to fold-const. Next release this should be covered.. we have a couple of options for exposing the new value-query API to fold_const and other consumers of the current get_range_info global interface. It's in the work queue to enable accessing the current ranger instance when its available, and fallback to the latest global value when there isn't one running. This should resolve this PR... stay tuned.
[Bug tree-optimization/83072] Late VRP optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83072 --- Comment #7 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:a5f9c27bfc4417224e332392bb81a2d733b2b5bf commit r11-5105-ga5f9c27bfc4417224e332392bb81a2d733b2b5bf Author: Andrew MacLeod Date: Tue Nov 17 10:04:38 2020 -0500 IOR with nonzero, range cannot contain 0. Remove zero from IOR ranges with non-zero masks. gcc/ PR tree-optimization/83072 * range-op.cc (wi_optimize_and_or): Remove zero from IOR range when mask is non-zero. gcc/testsuite/ * gcc.dg/pr83072.c: New.
[Bug c++/97871] [11 Regression] ICE in cp_parser_declaration, at cp/parser.c:13539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97871 --- Comment #3 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:c2cf58f0e3a32b803c890ea8daa8d9f550cf9888 commit r11-5104-gc2cf58f0e3a32b803c890ea8daa8d9f550cf9888 Author: Iain Sandoe Date: Tue Nov 17 16:28:30 2020 + C++ : Remove an overzealous checking assert [PR97871] It seems we accept __attribute__(()) without any diagnostic at present, so my added checking assert fires for something like: __attribute__ (()) int a; Fixed by removing the assert; in the case that the user enters something like: __attribute__ (()) extern "C" int foo; The diagnostic about attributes before linkage specs will fire and show the empty attributes. gcc/cp/ChangeLog: PR c++/97871 * parser.c (cp_parser_declaration): Remove checking assert.
[Bug target/97827] bootstrap error building the amdgcn-amdhsa offload compiler with LLVM 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97827
--- Comment #4 from Tobias Burnus ---
Draft patch (untested):
diff --git a/gcc/varasm.c b/gcc/varasm.c
index ada99940f65..51a507393a8 100644
--- a/gcc/varasm.c
+++ b/gcc/varasm.c
@@ -6738,9 +6738,11 @@ default_elf_asm_named_section (const char *name,
unsigned int flags,
/* If we have already declared this section, we can use an
abbreviated form to switch back to it -- unless this section is
part of a COMDAT groups, in which case GAS requires the full
- declaration every time. */
+ declaration every time. LLVM's MC linker requires that the
+ flags are identical, thus avoid the abbreviated form with MERGE. */
if (!(HAVE_COMDAT_GROUP && (flags & SECTION_LINKONCE))
- && (flags & SECTION_DECLARED))
+ && (flags & SECTION_DECLARED)
+ && !(flags & SECTION_MERGE))
{
fprintf (asm_out_file, "\t.section\t%s\n", name);
return;
[Bug libstdc++/97828] std::ranges::search_n does not work with counted_iterator<_List_iterator<...>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97828 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Patrick Palka --- Fixed for GCC 10.3 and 11, thanks for the bug report.
[Bug libstdc++/97828] std::ranges::search_n does not work with counted_iterator<_List_iterator<...>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97828 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:04cb64dadb5c115b4ad093ff92c3f5a0a87ef15f commit r10-9036-g04cb64dadb5c115b4ad093ff92c3f5a0a87ef15f Author: Patrick Palka Date: Tue Nov 17 10:28:20 2020 -0500 libstdc++: Fix ranges::search_n for random access iterators [PR97828] My ranges transcription of the std::search_n implementation for random access iterators missed a crucial part of the algorithm which the existing tests didn't exercise. When __remainder is less than __count at the start of an iteration of the outer while loop, it means we're continuing a partial match of __count - __remainder elements from the previous iteration. If at the end of the iteration we don't complete this partial match, we need to reset __remainder so that it's only offset by the size of the most recent partial match before starting the next iteration. This patch fixes this appropriately, mirroring how it's done in the corresponding std::search_n implementation. libstdc++-v3/ChangeLog: PR libstdc++/97828 * include/bits/ranges_algo.h (__search_n_fn::operator()): Check random_access_iterator before using the backtracking implementation. When the backwards scan fails prematurely, reset __remainder appropriately. * testsuite/25_algorithms/search_n/97828.cc: New test. (cherry picked from commit 8661f4faa875f361cd22a197774c1fa04cd0580b)
[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791 --- Comment #11 from CVS Commits --- The master branch has been updated by Aaron Sawdey : https://gcc.gnu.org/g:6b91b3e9df171970a907638d9b2e0bca1e792975 commit r11-5097-g6b91b3e9df171970a907638d9b2e0bca1e792975 Author: Aaron Sawdey Date: Wed Nov 4 13:54:25 2020 -0600 Add MODE_OPAQUE After discussion with Richard Sandiford on IRC, he suggested adding a new mode class MODE_OPAQUE to deal with the problems (PR 96791) we had been having with POImode/PXImode in powerpc target. This patch is the accumulation of changes I needed to make to add this and make it useable for the purposes of what power10 MMA needed. MODE_OPAQUE modes allow you to have modes for which you can just define loads and stores. By design, optimization does not expect to know how to do arithmetic or subregs on these modes. This allows us to have modes for multi-register vector operations where we don't want to open Pandora's Box and define general arithmetic operations. This patch will be followed by a target specific patch to change the powerpc power10 MMA builtins to use opaque modes, and will also let use use the vector pair loads/stores defined with that in the inline expansion of memcpy/memmove, allowing me to fix PR 96791. gcc/ChangeLog PR target/96791 * mode-classes.def: Add MODE_OPAQUE. * machmode.def: Add OPAQUE_MODE. * tree.def: Add OPAQUE_TYPE for types that will use MODE_OPAQUE. * doc/generic.texi: Document OPAQUE_TYPE. * doc/rtl.texi: Document MODE_OPAQUE. * machmode.h: Add OPAQUE_MODE_P(). * genmodes.c (complete_mode): Add MODE_OPAQUE. (opaque_mode): New function. * tree.c (tree_code_size): Add OPAQUE_TYPE. * tree.h: Add OPAQUE_TYPE_P(). * stor-layout.c (int_mode_for_mode): Treat MODE_OPAQUE modes like BLKmode. * ira.c (find_moveable_pseudos): Treat MODE_OPAQUE modes more like integer/float modes here. * dbxout.c (dbxout_type): Treat OPAQUE_TYPE like VOID_TYPE. * tree-pretty-print.c (dump_generic_node): Treat OPAQUE_TYPE like like other types.
[Bug libstdc++/97869] defines __cpp_lib_span even when doesn't provide an implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97869 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ecf65330c11544ebf35e198087b4a42be089c620 commit r11-5099-gecf65330c11544ebf35e198087b4a42be089c620 Author: Jonathan Wakely Date: Tue Nov 17 15:26:29 2020 + libstdc++: Fix unconditional definition of __cpp_lib_span in [PR 97869} The header is empty unless Concepts are supported, but defines the __cpp_lib_span feature test macro unconditionally. It should be guarded by the same conditions as in . libstdc++-v3/ChangeLog: PR libstdc++/97869 * include/precompiled/stdc++.h: Include . * include/std/version (__cpp_lib_span): Check __cpp_lib_concepts before defining.
[Bug c++/97839] Template lambda incorrectly requiring the optional lambda-declarator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97839 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug middle-end/97858] [11 regression] Bogus warnings about va_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858 --- Comment #11 from Jan Hubicka --- Jakub, with code patterns if (foo) ininit var ... if (foo) use var the false positive really depends on how far we do jump threading and similar transforms.
[Bug middle-end/97858] [11 regression] Bogus warnings about va_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858 Jan Hubicka changed: What|Removed |Added Status|RESOLVED|REOPENED Severity|normal |enhancement Component|bootstrap |middle-end Summary|[11 regression] Bogus |[11 regression] Bogus |warnings about va_list |warnings about va_list |during profiledbootstrap| Resolution|FIXED |--- --- Comment #10 from Jan Hubicka --- I have updated the PR to track the enhancements to -Wmaybe-uninitalized.
[Bug c++/97871] [11 Regression] ICE in cp_parser_declaration, at cp/parser.c:13539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97871
--- Comment #2 from Iain Sandoe ---
(In reply to Marek Polacek from comment #1)
> Started with r11-4927. Iain, I think the assert should go:
>
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -13536,7 +13536,6 @@ cp_parser_declaration (cp_parser* parser, tree
> prefix_attrs)
> {
>cp_lexer_save_tokens (parser->lexer);
>attributes = cp_parser_attributes_opt (parser);
> - gcc_checking_assert (attributes);
>cp_token *t1 = cp_lexer_peek_token (parser->lexer);
>cp_token *t2 = (t1->type == CPP_EOF
> ? t1 : cp_lexer_peek_nth_token (parser->lexer, 2));
ack, I'll take care of it, let me take a look at what it was guarding.
[Bug bootstrap/97858] [11 regression] Bogus warnings about va_list during profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858
--- Comment #9 from Jakub Jelinek ---
That said, can't reproduce with simplified:
void
foo (char *str, char *tail, ...)
{
__builtin_va_list ap;
if (tail)
__builtin_va_start (ap, tail);
for (int first = 1; str; first = 0)
{
*str = ' ';
if (first)
str = tail;
else
str = __builtin_va_arg (ap, char *);
}
if (tail)
__builtin_va_end (ap);
}
[Bug c++/97839] Template lambda incorrectly requiring the optional lambda-declarator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97839 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-17 --- Comment #1 from Marek Polacek --- Confirmed, thanks for reporting it.
[Bug c++/97871] [11 Regression] ICE in cp_parser_declaration, at cp/parser.c:13539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97871
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||iains at gcc dot gnu.org,
||mpolacek at gcc dot gnu.org
Last reconfirmed||2020-11-17
--- Comment #1 from Marek Polacek ---
Started with r11-4927. Iain, I think the assert should go:
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -13536,7 +13536,6 @@ cp_parser_declaration (cp_parser* parser, tree
prefix_attrs)
{
cp_lexer_save_tokens (parser->lexer);
attributes = cp_parser_attributes_opt (parser);
- gcc_checking_assert (attributes);
cp_token *t1 = cp_lexer_peek_token (parser->lexer);
cp_token *t2 = (t1->type == CPP_EOF
? t1 : cp_lexer_peek_nth_token (parser->lexer, 2));
[Bug target/97875] suboptimal loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875 --- Comment #2 from Christophe Lyon --- Checking the Arm v8-M manual, my understanding is that this architecture does not support unaligned vector loads/stores. However, my understanding is that vldrw.32 accepts to load from addresses aligned on 32 bits, which is the case since a and b are pointers to int32_t.
[Bug target/97872] [ARM NEON] Missed optimization for less-than comparison on vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97872
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-11-17
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener ---
So arm doesn't have a vec_cmp pattern that applies here? Before ISEL we have
vector(8) _1;
vector(8) signed char _2;
uint8x8_t _5;
[local count: 1073741824]:
_1 = a_3(D) < b_4(D);
_2 = VEC_COND_EXPR <_1, { -1, -1, -1, -1, -1, -1, -1, -1 }, { 0, 0, 0, 0, 0,
0, 0, 0 }>;
_5 = VIEW_CONVERT_EXPR(_2);
return _5;
and ISEL should be able to directly expand a_3(D) < b_4(D) via .VEC_CMP
Alternatively the backend should optimize vcond expansion when the
operands are all ones/zeros.
[Bug bootstrap/97858] [11 regression] Bogus warnings about va_list during profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858
--- Comment #8 from Jakub Jelinek ---
Well, so one enhancement request would be for va_list fields don't warn about
the internal fields, but warn about use of uninitialized va_list itself.
And the second thing is if the
if (tail)
va_start (ap, tail);
for (bool first = true; str; first = false)
{
use (str);
if (first)
str = tail;
else
str = va_arg (ap, char *);
}
if (tail)
va_end (ap);
is something uninit infrastructure should understand as never doing va_arg if
tail (the condition guarding va_start) is NULL.
[Bug c++/97874] [11 Regression] ICE: tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_using_decl, at cp/name-lookup.c:4652
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97874 Marek Polacek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Started with r11-5003: c++: Implement C++20 'using enum'.
[Bug target/97873] Failure to optimize abs optimally (at least one completely useless instruction on x86)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97873 --- Comment #2 from Richard Biener --- gcc-7 goes the x86 abs expander way: abs: .LFB0: .cfi_startproc movl%edi, %edx movl%edi, %eax sarl$31, %edx xorl%edx, %eax subl%edx, %eax ret
[Bug c++/97874] [11 Regression] ICE: tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_using_decl, at cp/name-lookup.c:4652
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97874 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-11-17 Status|UNCONFIRMED |NEW
[Bug target/97873] Failure to optimize abs optimally (at least one completely useless instruction on x86)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97873 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Target||x86_64-*-* i?86-*-* Status|UNCONFIRMED |NEW Component|tree-optimization |target Last reconfirmed||2020-11-17 --- Comment #1 from Richard Biener --- We're expanding from _2 = ABS_EXPR ; return _2; that's nothing to improve on the GIMPLE level. x86 has an abs expander that might or might not trigger (it doesn't look like for generic). We expand as insn 6 3 7 2 (parallel [ (set (reg:SI 85) (neg:SI (reg/v:SI 83 [ x ]))) (clobber (reg:CC 17 flags)) ]) "t.i":3:29 -1 (nil)) (insn 7 6 8 2 (parallel [ (set (reg:SI 84) (smax:SI (reg/v:SI 83 [ x ]) (reg:SI 85))) (clobber (reg:CC 17 flags)) ]) "t.i":3:29 -1 (nil)) (insn 8 7 12 2 (set (reg:SI 82 [ ]) (reg:SI 84)) "t.i":3:29 -1 (nil)) (insn 12 8 13 2 (set (reg/i:SI 0 ax) (reg:SI 82 [ ])) "t.i":4:1 -1 (nil)) where the smax:SI is late splitted IIRC. That's probably not the optimal expansion choice. I remember a duplicate bug.
[Bug libstdc++/97828] std::ranges::search_n does not work with counted_iterator<_List_iterator<...>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97828 --- Comment #8 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:8661f4faa875f361cd22a197774c1fa04cd0580b commit r11-5096-g8661f4faa875f361cd22a197774c1fa04cd0580b Author: Patrick Palka Date: Tue Nov 17 10:28:20 2020 -0500 libstdc++: Fix ranges::search_n for random access iterators [PR97828] My ranges transcription of the std::search_n implementation for random access iterators missed a crucial part of the algorithm which the existing tests didn't exercise. When __remainder is less than __count at the start of an iteration of the outer while loop, it means we're continuing a partial match of __count - __remainder elements from the previous iteration. If at the end of the iteration we don't complete this partial match, we need to reset __remainder so that it's only offset by the size of the most recent partial match before starting the next iteration. This patch fixes this appropriately, mirroring how it's done in the corresponding std::search_n implementation. libstdc++-v3/ChangeLog: PR libstdc++/97828 * include/bits/ranges_algo.h (__search_n_fn::operator()): Check random_access_iterator before using the backtracking implementation. When the backwards scan fails prematurely, reset __remainder appropriately. * testsuite/25_algorithms/search_n/97828.cc: New test.
[Bug c++/97874] [11 Regression] ICE: tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_using_decl, at cp/name-lookup.c:4652
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97874 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug tree-optimization/97875] suboptimal loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875 Richard Biener changed: What|Removed |Added Last reconfirmed||2020-11-17 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Richard Biener --- restrict is necessary because of possible aliasing (you see the runtime alias test). For orr r3, r2, r0 orrsr3, r3, r1 lslsr3, r3, #28 bne .L2 it looks like this is a runtime alignment test - does the specified arch support unaligned vector loads/stores?
[Bug bootstrap/97858] [11 regression] Bogus warnings about va_list during profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858 --- Comment #7 from Jan Hubicka --- > Fixed d7ab349c44f Thanks, my original intention was to mostly track the fact that we do not want to warn about fields of va_list type that is internal to compiler though :)
[Bug bootstrap/97314] bootstrap failure on i686-linux-gnu with --enable-checking=yes,extra,rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97314 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #3 from rsandifo at gcc dot gnu.org --- I see the same thing for arm-linux-gnueabihf on trunk, also on insn-extract.o. It's specific to RTL checking for me too. I found it does work if I bootstrap with --enable-checking=yes,extra, flip ENABLE_RTL_CHECKING to 1 in auto-host.h, and then recompile insn-extract.c. But it does take a large amount of VM: phase parsing : 51.10 ( 27%) 43.64 ( 74%) 94.74 ( 38%) 1334M ( 73%) This used to work “a while ago” but I don't know when it stopped. The file has 9975 lines, 435KiB, but that's a bairn compared to some of the stuff we kick out. Perhaps it's just the sheer number of (nested) XEXP macro expansions?
[Bug gcov-profile/96919] [GCOV] uncovered line of stack allocation while using virutal destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96919
Bhavana Kilambi changed:
What|Removed |Added
CC||bhavana.kilambi@blackfigtec
||h.com
--- Comment #8 from Bhavana Kilambi
---
This issue is reproducible in the trunk GCC version as well.
Reverting the commit 6e49961ce47b8c554ff6081ef95a68a0616f0a93 helps in
mitigating the issue. Specifically, the problem seems to lie in the
add_line_counts() code changes in the gcov.c file as shown below :
GCC8.2 gcc/gcov.c:
...
...
2540 has_any_line = true;
2541
2542 if (!ix || ix + 1 == fn->blocks.size ())
2543 /* Entry or exit block. */;
2544 else if (line != NULL)
2545 {
2546 line->blocks.push_back (block);
2547
2548 if (flag_branches)
2549 {
2550 arc_info *arc;
2551
2552 for (arc = block->succ; arc; arc = arc->succ_next)
2553 line->branches.push_back (arc);
...
...
Changing this part of the code to the one in the GCC7.5 version like this -
GCC8.2 gcc/gcov.c modified :
...
...
2541 if (!ix || ix + 1 == fn->blocks.size ())
2542 /* Entry or exit block. */;
2543 else if (flag_branches)
2544 {
2545 arc_info *arc;
2546
2547 for (arc = block->succ; arc; arc = arc->succ_next)
2548 {
2549 line->branches.push_back (arc);
2550 if (coverage && !arc->is_unconditional)
2551 add_branch_counts (coverage, arc);
...
...
Helped in getting a full 100% coverage in GCC8.2.
The executed line counts are being correctly updated for the source files until
line 2544 (in the original gcov.c version) after which the condition else if
(line != NULL) and the pushback of the block onto the line seems to be changing
the executed line counts. The modified version above (in accordance with the
code in gcc7.5) is able to get the desired coverage of 100% for the testcase
mentioned in this issue.
[Bug middle-end/97862] [11 Regression] ICE in expand_omp_for_init_vars, at omp-expand.c:2524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97862 --- Comment #3 from Jakub Jelinek --- Created attachment 49576 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49576&action=edit gcc11-pr97862.patch Untested fix.
[Bug bootstrap/97858] [11 regression] Bogus warnings about va_list during profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Nathan Sidwell --- Fixed d7ab349c44f
[Bug bootstrap/97858] [11 regression] Bogus warnings about va_list during profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858 --- Comment #5 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:d7ab349c44f30bed90b03b45865f6c7c5de1dfd8 commit r11-5095-gd7ab349c44f30bed90b03b45865f6c7c5de1dfd8 Author: Nathan Sidwell Date: Tue Nov 17 06:45:18 2020 -0800 preprocessor: Fix profiled bootstrap warning [pr97858] As Jakub points out, we only ever pass a single variadic parm (if at all), so just an optional arg is fine. PR preprocessor/97858 libcpp/ * mkdeps.c (munge): Drop varadic args, we only ever use one.
[Bug bootstrap/97857] [11 Regression] profiledbootstrap broken freeing speculative call summary since r11-4987-g602c6cfc79ce4ae61e277107e0a60079c1a93a97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857 Jan Hubicka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from Jan Hubicka --- Fixed.
