[Bug testsuite/105486] new test case gcc.dg/vect/bb-slp-pr104240.c from r13-71-g41e3db05d69740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105486 Richard Biener changed: What|Removed |Added CC|sayle at gcc dot gnu.org |rguenth at gcc dot gnu.org Summary|new test case |new test case |gcc.dg/vect/bb-slp-pr104240 |gcc.dg/vect/bb-slp-pr104240 |.c from |.c from |r13-89-gb3e98eb3396e16 |r13-71-g41e3db05d69740 |fails | Version|12.0|13.0 Ever confirmed|0 |1 Keywords||testsuite-fail Status|UNCONFIRMED |WAITING Last reconfirmed||2022-05-05 --- Comment #1 from Richard Biener --- The testcase is from my r13-71-g41e3db05d69740. Can you attach the slp2 dump file please? I suspect we're missing vect_hw_misalign support checking (but altering the testcase to use __builtin_assume_alignment () on all args should work as well). Can you check?
[Bug target/105484] [11/12/13 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -Os -march=cannonlake -fnon-call-exceptions -fno-tree-dce -fno-tree-forwprop since r11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105484 --- Comment #3 from Hongtao.liu --- Similar like PR104450, don't expand stmt to vec_set when there's EH on it.
[Bug c++/105489] New: Internal Compiler Error for 6 line source code (using C++20 modules) doing nothing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105489
Bug ID: 105489
Summary: Internal Compiler Error for 6 line source code (using
C++20 modules) doing nothing
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sandipan.mohanty at gmail dot com
Target Milestone: ---
Created attachment 52928
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52928&action=edit
Preprocessed source generated by g++ -freport-bug
The following 6 line code defining a struct with only one member type causes an
ICE in GCC git version (4 May 2022 / 4a2061610726becfa5158e418c69800f5634b4c1):
// Start : Module_ICE_1.cc
module;
import ;
export module SomeModule;
struct SomeClass {
using iterator = std::vector::iterator;
};
// End
Steps used to compile:
$ rm -rf gcm.cache
$ g++ -std=c++20 -fmodules-ts -xc++-system-header vector
$ g++ -std=c++20 -fmodules-ts -c Module_ICE_1.cc
Expected: (i) the module interface unit compiles without issues if code is
correct (ii) an error message from the compiler about what exactly is going
wrong, if the user code is incorrect
Not expected: compiler crash caused by 6 lines of user code.
Tested on: Reborn OS (Arch Linux), OpenSuSE 15.3, Kubuntu 22.04, Rocky Linux
(RHEL/CentOS/Fedora)
The release version of GCC 11.2.0 does not have this ICE.
The configuration options used to build GCC were:
../configure --prefix=blah --enable-languages=c,c++,fortran --disable-multilib
--enable-optimized --enable-linux-futex
I can do additional experiments if it will help detect/resolve this issue.
[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487 --- Comment #5 from Richard Biener --- When you say "if you set to a sysroot that doesn't contain any 32bit values, and thus doesn't contain the /sysroot/usr/lib directory at all but only has /sysroot/usr/lib64, then you can't compile GCC itself against that sysroot" can you please share the way you configure GCC (sources and build tree outside of the sysroot I presume) to compile it against such sysroot? Just for completeness and to be able to reproduce. While Andrew has a point, if the issue is simple enough to fix we should try.
[Bug target/105484] [11/12/13 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -Os -march=cannonlake -fnon-call-exceptions -fno-tree-dce -fno-tree-forwprop since r11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105484 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.4 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Richard Biener --- @@ -8,11 +21,15 @@ int _1; complex int _4; void * _10; + vector(4) int _12; + vector(4) int _13; [local count: 1073741824]: _4 = .MUL_OVERFLOW (i_3(D), 7); _1 = REALPART_EXPR <_4>; - VIEW_CONVERT_EXPR(v)[i_3(D)] = _1; + _12 = v; + _13 = .VEC_SET (_12, _1, i_3(D)); + v = _13; [local count: 1073741824]: bar (0); now I think in this case we can simply clear EH since the replacement can no longer throw.
[Bug target/105484] [11/12/13 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -Os -march=cannonlake -fnon-call-exceptions -fno-tree-dce -fno-tree-forwprop since r11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105484 --- Comment #5 from Richard Biener --- Created attachment 52929 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52929&action=edit patch in testing
[Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480 --- Comment #2 from seberg --- I still owed the correct example: https://godbolt.org/z/33Pj6xvPr Now I think the cause is the indeed (somewhat understandandable) desire to optimize away the branching. And not the instruction (I am not sure how the comparison instruction deals with trapping, so it could be both).
[Bug middle-end/105409] ICE in simplify_subreg, at simplify-rtx.cc:7351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105409 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > $ cc1plus -m32 -quiet m.x0-m_m2.cpp > m.x0-m_m2.cpp:111:1: internal compiler error: in simplify_subreg, at > simplify-rtx.cc:7351 > 111 | } > | ^ If one compiles the testcase with a sparcv9-sun-solaris2.11 g++, it works just fine. However, the cc1plus invocation is different: cc1plus -mptr32 -mno-stack-bias -quiet -m32 -mcpu=v9 m.x0-m_m2.cpp Omitting the -mptr32 lets the ICE resurface. It seems gm2 omits CC1_SPEC from the cc1/cc1plus invocation in gcc/m2/m2-link-support.h.
[Bug tree-optimization/104595] unvectorized loop due to bool condition loaded from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104595 --- Comment #11 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:938a02a589dc22cef65bba2b131fc9e4874baddb commit r13-128-g938a02a589dc22cef65bba2b131fc9e4874baddb Author: Richard Biener Date: Mon Feb 21 11:05:58 2022 +0100 tree-optimization/104595 - vectorization of COND_EXPR with bool load The following fixes an omission in bool pattern detection that makes it fail when check_bool_pattern fails for COND_EXPR. That's not what it should do, instead it should still pattern recog to var != 0 even if no further adjustments to the def chain are necessary when var is not a mask already. 2022-02-21 Richard Biener PR tree-optimization/104595 * tree-vect-patterns.cc (vect_recog_bool_pattern): For COND_EXPR do not fail if check_bool_pattern returns false. * gcc.dg/vect/pr104595.c: New testcase.
[Bug target/105484] [11/12/13 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -Os -march=cannonlake -fnon-call-exceptions -fno-tree-dce -fno-tree-forwprop since r11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105484 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e1a41143a2e24c65d94364fd82b165ff71a759d8 commit r13-129-ge1a41143a2e24c65d94364fd82b165ff71a759d8 Author: Richard Biener Date: Thu May 5 09:34:59 2022 +0200 tree-optimization/105484 - VEC_SET and EH When the IL representation of VEC_SET is marked as throwing (unnecessarily), we need to clean that when replacing it with the .VEC_SET internal function call which cannot throw. 2022-05-05 Richard Biener PR tree-optimization/105484 * gimple-isel.cc (gimple_expand_vec_set_expr): Clean EH, return whether the CFG changed. (gimple_expand_vec_exprs): When the CFG changed, clean it up. * gcc.dg/torture/pr105484.c: New testcase.
[Bug target/105484] [11/12 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -Os -march=cannonlake -fnon-call-exceptions -fno-tree-dce -fno-tree-forwprop since r11-50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105484 Richard Biener changed: What|Removed |Added Known to fail|13.0| Priority|P3 |P2 Known to work||13.0 Summary|[11/12/13 Regression] ICE: |[11/12 Regression] ICE: |verify_flow_info failed: BB |verify_flow_info failed: BB |2 cannot throw but has an |2 cannot throw but has an |EH edge with -Os|EH edge with -Os |-march=cannonlake |-march=cannonlake |-fnon-call-exceptions |-fnon-call-exceptions |-fno-tree-dce |-fno-tree-dce |-fno-tree-forwprop since|-fno-tree-forwprop since |r11-5074-g287cc750b0887e86 |r11-5074-g287cc750b0887e86 --- Comment #7 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/105490] New: unvectorized loop due to bool condition loaded from memory and different size data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105490
Bug ID: 105490
Summary: unvectorized loop due to bool condition loaded from
memory and different size data
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
Cloned from PR104595
#define N 256
typedef short T;
extern T a[N];
extern T b[N];
extern T c[N];
extern _Bool pb[N];
void predicate_by_bool()
{
for (int i = 0; i < N; i++)
c[i] = pb[i] ? a[i] : b[i];
}
where we expect vect_recog_mask_conversion_pattern to trigger here. That
case can be fixed with
@@ -4658,9 +4660,9 @@ vect_recog_mask_conversion_pattern (vec_info *vinfo,
if (TREE_CODE (rhs1) == SSA_NAME)
{
- rhs1_type = integer_type_for_mask (rhs1, vinfo);
- if (!rhs1_type)
+ if (integer_type_for_mask (rhs1, vinfo))
return NULL;
+ rhs1_type = TREE_TYPE (rhs1);
}
else if (COMPARISON_CLASS_P (rhs1))
{
but we then run into the original issue again:
t.c:10:6: missed: not vectorized: relevant stmt not supported: patt_28 =
() _1;
The cruical difference between working and not working is the _1 != 0 ?: vs.
_1 ?: - I think we do have a duplicate bugreport here, possibly involving
combinations of different from memory bools.
Trying to make bool pattern recog inserting the relevant compensation code
is really iffy, the mask conversion pattern confuses things here - what
we are missing seems really be transforming the leafs.
Note that we do not try to patter-recog a pattern thus we cannot at the moment
have both, vect_recog_bool_pattern and vect_recog_mask_conversion_pattern
at the same time on the ?: stmt.
Note IIRC vect_recog_bool_pattern has to come last but it's now after
vect_recog_mask_conversion_pattern. Unfortunately swapping things does
not make vect_recog_bool_pattern recognize and fixup
patt_24 = () _1;
[Bug tree-optimization/105490] unvectorized loop due to bool condition loaded from memory and different size data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105490 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-05-05 Blocks||53947 Keywords||missed-optimization Status|UNCONFIRMED |NEW Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/104595] unvectorized loop due to bool condition loaded from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104595 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Known to work||13.0 Status|ASSIGNED|RESOLVED --- Comment #12 from Richard Biener --- Fixed, I've opened PR105490 for the case where we need widening.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 104595, which changed state. Bug 104595 Summary: unvectorized loop due to bool condition loaded from memory https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104595 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug testsuite/105486] new test case gcc.dg/vect/bb-slp-pr104240.c from r13-71-g41e3db05d69740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105486 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:000f4480005035d0811e009a7cb25b42721f0a6e commit r13-130-g000f4480005035d0811e009a7cb25b42721f0a6e Author: Richard Biener Date: Thu May 5 10:41:08 2022 +0200 testsuite/105486 - adjust testcase to avoid misaligned accesses This properly aligns data, increasing test coverage. 2022-05-05 Richard Biener PR testsuite/105486 * gcc.dg/vect/bb-slp-pr104240.c: Align all data.
[Bug testsuite/105486] new test case gcc.dg/vect/bb-slp-pr104240.c from r13-71-g41e3db05d69740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105486 --- Comment #3 from Richard Biener --- So alignment is definitely going to be a problem so I fixed that. Does this resolve the FAIL on ppc64?
[Bug c++/105491] New: Usafe of __constinit with -std=c++ does is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105491
Bug ID: 105491
Summary: Usafe of __constinit with -std=c++ does is rejected
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
Target Milestone: ---
Created attachment 52930
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52930&action=edit
test-case
Noticed that in protobuf package:
https://github.com/protocolbuffers/protobuf/issues/9916
$ g++ 12.ii -c -std=c++11
x.cc:39:123: error: ‘constinit’ variable
‘_ProtobufCFileOptions_default_instance_’ does not have a constant initializer
39 | PROTOBUF_ATTRIBUTE_NO_DESTROY PROTOBUF_CONSTINIT
PROTOBUF_ATTRIBUTE_INIT_PRIORITY1 ProtobufCFileOptionsDefaultTypeInternal
_ProtobufCFileOptions_default_instance_;
|
^~~
x.cc:39:123: error:
‘ProtobufCFileOptionsDefaultTypeInternal{ProtobufCFileOptionsDefaultTypeInternal::{ProtobufCFileOptions{google::protobuf::Message{google::protobuf::MessageLite{((&
ProtobufCFileOptions::_ZTV20ProtobufCFileOptions) + 16),
google::protobuf::internal::InternalMetadata{0}}},
google::protobuf::internal::HasBits<1>{uint32_t [1]()},
google::protobuf::internal::CachedSize{std::atomic{std::__atomic_base{0}}},
google::protobuf::internal::ArenaStringPtr{google::protobuf::internal::TaggedStringPtr{((void*)(&
google::protobuf::internal::fixed_address_empty_string))}}, false, false,
false, true, true}}}’ is not a constant expression
x.cc:53:126: error: ‘constinit’ variable
‘_ProtobufCMessageOptions_default_instance_’ does not have a constant
initializer
53 | PROTOBUF_ATTRIBUTE_NO_DESTROY PROTOBUF_CONSTINIT
PROTOBUF_ATTRIBUTE_INIT_PRIORITY1 ProtobufCMessageOptionsDefaultTypeInternal
_ProtobufCMessageOptions_default_instance_;
|
^~
x.cc:53:126: error:
‘ProtobufCMessageOptionsDefaultTypeInternal{ProtobufCMessageOptionsDefaultTypeInternal::{ProtobufCMessageOptions{google::protobuf::Message{google::protobuf::MessageLite{((&
ProtobufCMessageOptions::_ZTV23ProtobufCMessageOptions) + 16),
google::protobuf::internal::InternalMetadata{0}}},
google::protobuf::internal::HasBits<1>{uint32_t [1]()},
google::protobuf::internal::CachedSize{std::atomic{std::__atomic_base{0}}},
google::protobuf::internal::ArenaStringPtr{google::protobuf::internal::TaggedStringPtr{0}},
false, true}}}’ is not a constant expression
x.cc:65:124: error: ‘constinit’ variable
‘_ProtobufCFieldOptions_default_instance_’ does not have a constant initializer
65 | PROTOBUF_ATTRIBUTE_NO_DESTROY PROTOBUF_CONSTINIT
PROTOBUF_ATTRIBUTE_INIT_PRIORITY1 ProtobufCFieldOptionsDefaultTypeInternal
_ProtobufCFieldOptions_default_instance_;
|
^~~~
x.cc:65:124: error:
‘ProtobufCFieldOptionsDefaultTypeInternal{ProtobufCFieldOptionsDefaultTypeInternal::{ProtobufCFieldOptions{google::protobuf::Message{google::protobuf::MessageLite{((&
ProtobufCFieldOptions::_ZTV21ProtobufCFieldOptions) + 16),
google::protobuf::internal::InternalMetadata{0}}},
google::protobuf::internal::HasBits<1>{uint32_t [1]()},
google::protobuf::internal::CachedSize{std::atomic{std::__atomic_base{0}}},
false}}}’ is not a constant expression
x.cc: In member function ‘virtual uint8_t*
ProtobufCMessageOptions::_InternalSerialize(uint8_t*,
google::protobuf::io::EpsCopyOutputStream*) const’:
x.cc:499:1: warning: no return statement in function returning non-void
[-Wreturn-type]
499 | }
| ^
$ g++ 12.ii -c -std=c++17
x.cc: In member function ‘virtual uint8_t*
ProtobufCMessageOptions::_InternalSerialize(uint8_t*,
google::protobuf::io::EpsCopyOutputStream*) const’:
x.cc:499:1: warning: no return statement in function returning non-void
[-Wreturn-type]
499 | }
| ^
[Bug testsuite/105486] new test case gcc.dg/vect/bb-slp-pr104240.c from r13-71-g41e3db05d69740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105486 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com Target Milestone|--- |13.0 Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com --- Comment #4 from Roger Sayle --- I think the mention of slp2 and pr104240.c in the bug report is bogus, and is a glitch in the automated regression checking scripts. The real problem is that my new test case for pr102950.c is failing on powerpc64. After a great deal of head scratching on why EVRP is producing different results on this platform, I've just realized that "char" must be unsigned on this target. Replacing "char" with "signed char" in gcc.dg/pr102950.c fixes the problem. I'll commit this fix as obvious. But I want to avoid anyone wasting time (like I did) trying to figure out why my patch should be the cause of an -flto failure of bb-slp-pr104240.c [which might be failure, but unrelated to the pr102950.c issue/bisect].
[Bug c/105492] New: [13 Regression] ICE in set_underlying_type, at c-family/c-common.cc:8164
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105492 Bug ID: 105492 Summary: [13 Regression] ICE in set_underlying_type, at c-family/c-common.cc:8164 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com CC: jason at gcc dot gnu.org Target Milestone: --- Target: powerpc-*-linux-gnu g++ (and gcc as well) 13.0.0 20220501 snapshot (g:75bbc3da3e5f75f683fa33e309045c582efd20eb) ICEs when compiling gcc/testsuite/gcc.target/powerpc/pr83660.C w/ -maltivec: % powerpc-e300c3-linux-gnu-g++-13.0.0 -maltivec -c gcc/testsuite/gcc.target/powerpc/pr83660.C gcc/testsuite/gcc.target/powerpc/pr83660.C:7:73: internal compiler error: in set_underlying_type, at c-family/c-common.cc:8164 7 | typedef __vector unsigned int uvec32_t __attribute__((__aligned__(16))); | ^ 0x6c4f25 set_underlying_type(tree_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/c-family/c-common.cc:8164 0xa27fb3 pushdecl(tree_node*, bool) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/name-lookup.cc:3801 0x978103 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int, tree_node*, tree_node*, tree_node**) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/decl.cc:5764 0xa74fa5 cp_parser_init_declarator /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:22695 0xa4f6a3 cp_parser_simple_declaration /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:15280 0xa808f5 cp_parser_declaration /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:14966 0xa8137a cp_parser_toplevel_declaration /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:14987 0xa8137a cp_parser_translation_unit /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:5010 0xa8137a c_parse_file() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:48113 0xbbd5dd c_common_parse_file() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/c-family/c-opts.cc:1240 The failing assert was introduced in r13-57-g0aa277bf0b4b7943.
[Bug c++/105491] Usage of __constinit with -std=c++11 does is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105491 --- Comment #1 from Jonathan Wakely --- The constexpr rules in C++11 are much stricter, this is probably user error (i.e. C++20 constinit can't be used here).
[Bug c++/105481] [9/10/11/12/13 Regression] ICE: unexpected expression of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105481 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- more reduced: template struct uint; template uint f(const uint &); template> uint f(T); using X = uint<1>; X (*fp)(X const &) = f;
[Bug target/105493] New: [12/13 Regression] x86_64 538.imagick_r 6% regressions and 2% 525.x264_r regressions on Alder Lake after r12-7319-g90d693bdc9d718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105493 Bug ID: 105493 Summary: [12/13 Regression] x86_64 538.imagick_r 6% regressions and 2% 525.x264_r regressions on Alder Lake after r12-7319-g90d693bdc9d718 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: lili.cui at intel dot com Target Milestone: --- Similar issue with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104762 they are all caused by the same commit 90d693bdc9d71841f51d68826ffa5bd685d7f0bc options: -march=native -Ofast -lto Alder Lake single copy: after Vs. before this commit 525.x264_r -9.09% 538.imagick_r-25.00% Alder Lake multicopy: after Vs. before this commit 525.x264_r -2.00% 538.imagick_r-6.7%
[Bug target/105493] [12/13 Regression] x86_64 538.imagick_r 6% regressions and 2% 525.x264_r regressions on Alder Lake after r12-7319-g90d693bdc9d718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105493 Richard Biener changed: What|Removed |Added Keywords||missed-optimization CC||jamborm at gcc dot gnu.org Target||x86_64-*-* Blocks||26163 Target Milestone|--- |12.0 --- Comment #1 from Richard Biener --- Martin is currently re-benchmarking GCC 12 on AMD, so let's see if there's anything left on those. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug c/105492] [13 Regression] ICE in set_underlying_type, at c-family/c-common.cc:8164
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105492 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug c++/105481] [9/10/11/12/13 Regression] ICE: unexpected expression of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105481 --- Comment #4 from Patrick Palka --- During type_unification_real as part of partial ordering, when considering default template arguments we assume all previously deduced arguments are non-dependent and therefore default argument instantiation will be non-dependent. But I don't think that's true for partial ordering, where we may end up deducing dependent arguments e.g. deducing N for N in the comment #3 testcase.
[Bug testsuite/105486] new test case gcc.dg/vect/bb-slp-pr104240.c from r13-71-g41e3db05d69740
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105486 --- Comment #5 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:92fff39f06449f907d8781a5dcaad0e8b9743480 commit r13-136-g92fff39f06449f907d8781a5dcaad0e8b9743480 Author: Roger Sayle Date: Thu May 5 08:30:27 2022 -0400 [Committed] PR testsuite/105486: Use "signed char" in gcc.dg/pr102950.c Although the automated regression testing scripts for powerpc64 appear to be somewhat garbled at the moment, they've correctly identified that my new test case for pr102950.c is failing on powerpc64, as char by default is unsigned on this target. This patch tweaks the new testcase by explicitly using "signed char" so that it's testing the intended EVRP behaviour portably. Committed as obvious. 2022-05-05 Roger Sayle gcc/testsuite/ChangeLog PR testsuite/105486 * gcc.dg/pr102950.c: Use explicit "signed char" in test case.
[Bug c++/105481] [9/10/11/12/13 Regression] ICE: unexpected expression of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105481 --- Comment #5 from Patrick Palka --- Here's a closely related rejects-valid (rather than ICE-on-valid) testcase, where the default argument is now T instead of uint (which shouldn't affect the outcome of partial ordering): template struct uint; template uint f(const uint &); // #1 template uint f(T); // #2 using X = uint<1>; X (*fp)(X const &) = f; // should use #1, instead diagnoses as ambiguous
[Bug tree-optimization/104162] [12/13 Regression] Missed CSE after lowering of &MEM[ptr_1 + CST]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104162 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ee1cb43bc76de800efa0ade687b0cd28e62a5f82 commit r13-137-gee1cb43bc76de800efa0ade687b0cd28e62a5f82 Author: Richard Biener Date: Wed Jan 26 15:34:54 2022 +0100 tree-optimization/104162 - CSE of &MEM[ptr].a[i] and ptr + CST This adds the capability to value-numbering of treating complex address expressions where the offset becomes invariant as equal to a POINTER_PLUS_EXPR. This restores CSE that is now prevented by early lowering of &MEM[ptr + CST] to a POINTER_PLUS_EXPR. Unfortunately this regresses gcc.dg/asan/pr99673.c again, so the testcase is adjusted accordingly. 2022-01-26 Richard Biener PR tree-optimization/104162 * tree-ssa-sccvn.cc (vn_reference_lookup): Handle &MEM[_1 + 5].a[i] like a POINTER_PLUS_EXPR if the offset becomes invariant. (vn_reference_insert): Likewise. * gcc.dg/tree-ssa/ssa-fre-99.c: New testcase. * gcc.dg/asan/pr99673.c: Adjust.
[Bug sanitizer/99673] [11/13 Regression] bogus -Wstringop-overread warning with address sanitizer due to member address substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673 Richard Biener changed: What|Removed |Added Summary|[11 Regression] bogus |[11/13 Regression] bogus |-Wstringop-overread warning |-Wstringop-overread warning |with address sanitizer due |with address sanitizer due |to member address |to member address |substitution|substitution Known to fail||13.0 --- Comment #12 from Richard Biener --- Broken again for GCC 13 by r13-137-gee1cb43bc76de8 which restores the CSE.
[Bug gcov-profile/105210] gcc/auto-profile.cc:391:11: warning: variable 'level' set but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105210 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Martin Liška --- Should be fixed with g:880456ed99d23ae76be4ecc929bcbcf8cae5eb66.
[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug 89180 depends on bug 105210, which changed state. Bug 105210 Summary: gcc/auto-profile.cc:391:11: warning: variable 'level' set but not used https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105210 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/101891] Adjust -fzero-call-used-regs to always use XOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891 qinzhao at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |13.0
[Bug c++/105494] New: syntax error with requires { []{}(); };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105494
Bug ID: 105494
Summary: syntax error with requires { []{}(); };
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
maybe dup of PR99546, PR105222.
int main() {
requires { []{}(); };// syntax error
requires { []{ ??? }; }; // no syntax error
}
https://godbolt.org/z/rfnssoe3T
[Bug c++/105494] syntax error with requires { []{}(); };
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105494 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-05-05 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed.
[Bug middle-end/105409] ICE in simplify_subreg, at simplify-rtx.cc:7351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105409
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> It seems gm2 omits CC1_SPEC from the cc1/cc1plus invocation in
> gcc/m2/m2-link-support.h.
Indeed: the following trivial patch works wonders indeed:
diff --git a/gcc/m2/m2-link-support.h b/gcc/m2/m2-link-support.h
--- a/gcc/m2/m2-link-support.h
+++ b/gcc/m2/m2-link-support.h
@@ -52,7 +52,7 @@ along with GCC; see the file COPYING3.
compiler. */
#define GM2CC(INPUT,OUTPUT) \
- "%{!fno-exceptions:cc1plus;:cc1} " GM2CC_OPTIONS " " INPUT " \
+ "%{!fno-exceptions:cc1plus;:cc1} %1 " GM2CC_OPTIONS " " INPUT " \
-o %d" SCAFFOLDNAME ".s \n\
" AS(SCAFFOLDNAME ".s",OUTPUT) " "
With it, I get the following test results on sparcv9-sun-solaris2.11:
=== gm2 Summary for unix ===
# of expected passes11721
# of unexpected failures7
# of unresolved testcases 1
=== gm2 Summary for unix/-m32 ===
# of expected passes11706
# of unexpected failures22
# of unresolved testcases 1
=== gm2 Summary ===
# of expected passes23427
# of unexpected failures29
# of unresolved testcases 2
[Bug c/105492] [13 Regression] ICE in set_underlying_type, at c-family/c-common.cc:8164 since r13-57-g0aa277bf0b4b7943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105492 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2022-05-05 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|[13 Regression] ICE in |[13 Regression] ICE in |set_underlying_type, at |set_underlying_type, at |c-family/c-common.cc:8164 |c-family/c-common.cc:8164 ||since ||r13-57-g0aa277bf0b4b7943
[Bug c/105495] New: `__atomic_compare_exchange` prevents tail-call optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105495
Bug ID: 105495
Summary: `__atomic_compare_exchange` prevents tail-call
optimization
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Godbolt: https://gcc.godbolt.org/z/7ob6zc17P
Offending testcase:
```c
typedef struct { int b; } cond;
int
__MCF_batch_release_common(cond* p, int c);
int
_MCF_cond_signal_some(cond* p, int x)
{
cond c = {x}, n = {2};
__atomic_compare_exchange(p, &c, &n, 1, 0, 0);
return __MCF_batch_release_common(p, x);
}
```
GCC output:
```asm
_MCF_cond_signal_some:
sub rsp, 24
mov edx, 2
mov eax, esi
mov DWORD PTR [rsp+12], esi
lock cmpxchgDWORD PTR [rdi], edx
je .L2
mov DWORD PTR [rsp+12], eax <--- note this extra store,
which clang doesn't generate
.L2:
call__MCF_batch_release_common
add rsp, 24
ret
```
Clang output:
```asm
_MCF_cond_signal_some: # @_MCF_cond_signal_some
mov ecx, 2
mov eax, esi
lockcmpxchg dword ptr [rdi], ecx
jmp __MCF_batch_release_common # TAILCALL
```
1. If `cond` was defined as a scalar type such as `long`, there is no such
issue.
2. `__atomic_exchange` doesn't suffer from this issue.
[Bug c/105495] `__atomic_compare_exchange` prevents tail-call optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105495
--- Comment #1 from LIU Hao ---
A possible workaround is to use a scalar type to provide storage for local
variables, and cast them as needed:
Godbolt: https://gcc.godbolt.org/z/n7zq7Pn4G
```c
typedef struct { int b; } cond;
int
__MCF_batch_release_common(cond* p, int c);
int
_MCF_cond_signal_some(cond* p, int x)
{
int c = {x}, n = {2};
__atomic_compare_exchange((cond*)p, (cond*)&c, (cond*)&n, 1, 0, 0);
return __MCF_batch_release_common(p, x);
}
```
This makes GCC output the same assembly as Clang.
[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487 --- Comment #6 from Paul Smith --- If it is really required, then the GCC configure script or makefile or something should detect this situation and fail. There's nothing in the current build system or documentation that says this is needed and I don't see how any reasonable person would be expected to guess this. My personal opinion is that it's not correct to require unwanted and unnecessary directories to exist, just so that relative pathname lookups to completely unrelated directories can succeed. Here's how to reproduce: * Create an empty directory. * Obtain the necessary 64bit library packages (for example, the 64bit versions of glibc / glibc-common / glibc-devel / glibc-headers / libgcc RPMs from a CentOS repository--you might need kernel-headers too). * Unpack them into the empty directory (for example, using rpm2cpio). * Build GCC with that directory as the sysroot. * Witness failure. The 64bit library RPMs do not (as they shouldn't!) create or put any content into the /usr/lib directory, so it won't exist in your sysroot. In order to have /usr/lib show up, you have to either install the 32bit library packages, which we don't want or need, or else understand enough about what's going on to create that directory by hand (and dump a ".keep" file or something in it to be sure that empty directory pruning doesn't delete it again).
[Bug c/105495] `__atomic_compare_exchange` prevents tail-call optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105495 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-05-05 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Richard Biener --- The issue is that we pass the 2nd argument by reference which causes a stack slot to be allocated for 'c': c.b = x_2(D); __atomic_compare_exchange_4 (p_4(D), &c, 2, 1, 0, 0);
[Bug target/105496] New: Comparison optimizations result in unnecessary cmp instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105496
Bug ID: 105496
Summary: Comparison optimizations result in unnecessary cmp
instructions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/1zdYsaqEj
Consider these equivalent functions:
int test1(int x) {
if (x <= 10)
return 123;
if (x == 11)
return 456;
return 789;
}
int test2(int x) {
if (x < 11)
return 123;
if (x == 11)
return 456;
return 789;
}
In test2 it is very clear that you can do a single cmp of x with 11 then use
different flag bits to choose your case. In test1 it is less clear, but because
x<=10 and x<11 are equivalent, you could always transform one to the other.
Clang seems to do this correctly and transforms test1 into test2 and only emits
a single cmp instruction in each. For some reason, not only does gcc miss this
optimization, it seems to go the other direction and transform test2 into
test1, emitting 2 cmp instructions for both!
test1(int):
mov eax, 123
cmp edi, 10
jle .L1
cmp edi, 11
mov eax, 456
mov edx, 789
cmovne eax, edx
.L1:
ret
test2(int):
mov eax, 123
cmp edi, 10
jle .L6
cmp edi, 11
mov eax, 456
mov edx, 789
cmovne eax, edx
.L6:
ret
Observed with at least -O2 and -O3. I initially observed this for code where
each if generated an actual branch rather than a cmov, but when I reduced the
example, the cmov was generated.
I'm not sure if this should be a middle-end or target specific optimization,
since ideally it would be smart on all targets that use comparison flags, even
if there are some targets that don't. Is there ever a down side to trying to
make two adjacent comparisons compare the same number?
[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487 --- Comment #7 from Paul Smith --- Just to be clear when I say "Build GCC with that directory as the sysroot" I mean something like this: ../gcc-11.3.0/configure --with-sysroot=/sysroot ...
[Bug c/105492] [13 Regression] ICE in set_underlying_type, at c-family/c-common.cc:8164 since r13-57-g0aa277bf0b4b7943
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105492 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c/105495] `__atomic_compare_exchange` prevents tail-call optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105495 --- Comment #3 from LIU Hao --- Wouldn't that go away if the value in it is never read back?
[Bug c/105495] `__atomic_compare_exchange` prevents tail-call optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105495 --- Comment #4 from Jakub Jelinek --- The reason why it works in #c1 is that we replace the c = x_4(D); n_6 = 2; n.0_1 = n_6; n.1_2 = (unsigned int) n.0_1; __atomic_compare_exchange_4 (p_7(D), &c, n.1_2, 1, 0, 0); call in the IL with: c_20 = x_4(D); _15 = c_20; _16 = VIEW_CONVERT_EXPR(_15); _17 = .ATOMIC_COMPARE_EXCHANGE (p_7(D), _16, 2, 260, 0, 0); _18 = REALPART_EXPR <_17>; _19 = VIEW_CONVERT_EXPR(_18); c_21 = _19; during ccp1 pass, optimizing away the addressables. But we don't do that for aggregates with sizes of integer types, but supposedly we could do that too.
[Bug c++/105491] Usage of __constinit with -std=c++11 does is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105491
--- Comment #2 from Marek Polacek ---
Reduced. Works with -std=c++17 but not 14. It's about the union in
ProtobufCFileOptionsDefaultTypeInternal.
class Message {
virtual int GetMetadata();
};
class ProtobufCFileOptions : Message {
public:
constexpr ProtobufCFileOptions(int);
bool no_generate_;
bool const_strings_;
bool use_oneof_field_name_;
bool gen_pack_helpers_;
bool gen_init_helpers_;
};
constexpr ProtobufCFileOptions::ProtobufCFileOptions(int)
: no_generate_(), const_strings_(), use_oneof_field_name_(),
gen_pack_helpers_(), gen_init_helpers_() {}
struct ProtobufCFileOptionsDefaultTypeInternal {
constexpr ProtobufCFileOptionsDefaultTypeInternal() : _instance({}) {}
union {
ProtobufCFileOptions _instance;
};
} __constinit _ProtobufCFileOptions_default_instance_;
[Bug c++/105491] [10/11/12/13 Regression] Usage of __constinit with -std=c++11 does is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105491
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2022-05-05
Target Milestone|--- |10.4
Summary|Usage of __constinit with |[10/11/12/13 Regression]
|-std=c++11 does is rejected |Usage of __constinit with
||-std=c++11 does is rejected
CC||jakub at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #3 from Jakub Jelinek ---
Related
class Message {
virtual int GetMetadata();
};
class ProtobufCFileOptions : Message {
public:
constexpr ProtobufCFileOptions(int);
bool no_generate_;
bool const_strings_;
bool use_oneof_field_name_;
bool gen_pack_helpers_;
bool gen_init_helpers_;
};
constexpr ProtobufCFileOptions::ProtobufCFileOptions(int)
: no_generate_(), const_strings_(), use_oneof_field_name_(),
gen_pack_helpers_(), gen_init_helpers_() {}
struct ProtobufCFileOptionsDefaultTypeInternal {
constexpr ProtobufCFileOptionsDefaultTypeInternal() : _instance({}) {}
union {
ProtobufCFileOptions _instance;
};
};
constexpr ProtobufCFileOptionsDefaultTypeInternal
_ProtobufCFileOptions_default_instance_;
is rejected starting with r10-7313-gb599bf9d6d1e180d350b71e51e08a66a1bb1546a
when using -std=c++11 or -std=c++14.
Though, I don't see how it could be changing the active union member when there
is just one member...
[Bug c++/105491] [10/11/12/13 Regression] Usage of __constinit with -std=c++11 does is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105491 --- Comment #4 from Marek Polacek --- I think this is a genuine bug that started with r10-7313-gb599bf9d6d1e18.
[Bug c++/105491] [10/11/12/13 Regression] Usage of __constinit with -std=c++11 does is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105491
--- Comment #5 from Marek Polacek ---
// PR c++/105491
struct V {
virtual int foo();
};
struct S : V {
constexpr S(int) : b() { }
bool b;
};
struct W {
constexpr W() : s({}) {}
union {
S s;
};
};
constexpr W w;
[Bug c/105488] Function definition is not generated OR function is not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105488 --- Comment #3 from Pavel M --- To: Andrew Pinski Indeed, per C11: > It is unspecified whether a call to the function uses the inline definition > or the external definition. Thanks!
[Bug c++/105491] [10/11/12/13 Regression] Usage of __constinit with -std=c++11 does is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105491 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P2
[Bug c++/105491] [10/11/12/13 Regression] Usage of __constinit with -std=c++11 does is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105491 --- Comment #6 from Marek Polacek --- And since it only happens with a polymorphic class, my bet is that we think there are two members because one is the artificial vtable for S and the other is the bool. I can poke more.
[Bug middle-end/105495] `__atomic_compare_exchange` prevents tail-call optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105495 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|c |middle-end
[Bug c++/105497] New: -Wswitch ignores [[maybe_unused]] for an enumerator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105497
Bug ID: 105497
Summary: -Wswitch ignores [[maybe_unused]] for an enumerator
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: olafurw at gmail dot com
Target Milestone: ---
enum class Button
{
Left,
Right,
Middle,
NumberOfButtons [[maybe_unused]]
};
int main()
{
Button b = Button::Left;
switch (b) {
case Button::Left:
case Button::Right:
case Button::Middle:
break;
//#ifdef __GNUC__
//case Button::NumberOfButtons:
//__builtin_unreachable();
//#endif
}
}
https://godbolt.org/z/d5M5MYc45
No warning generated for Clang or MSVC but it does for GCC. Works with
__builtin_unreachable()
LLVM bug report about the same thing:
https://bugs.llvm.org/show_bug.cgi?id=36231
[Bug c++/105497] -Wswitch ignores [[maybe_unused]] for an enumerator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105497 Marek Polacek changed: What|Removed |Added Last reconfirmed||2022-05-05 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||diagnostic CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Ah, that's interesting. Confirmed.
[Bug c++/105497] -Wswitch ignores [[maybe_unused]] for an enumerator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105497 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug gcov-profile/105210] gcc/auto-profile.cc:391:11: warning: variable 'level' set but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105210 --- Comment #10 from David Binderman --- (In reply to Martin Liška from comment #9) > Should be fixed with g:880456ed99d23ae76be4ecc929bcbcf8cae5eb66. Presumably there's a good reason why the one in file libdecnumber/dpd/decimal64.c didn't get fixed ?
[Bug middle-end/105409] ICE in simplify_subreg, at simplify-rtx.cc:7351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105409 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Gaius Mulley --- Many thanks for the patch, diagnosis and test - I've applied the patch on the modula2 branch.
[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105487
--- Comment #8 from joseph at codesourcery dot com ---
I expect you'd also see this issue with build-many-glibcs.py (from glibc)
if you remove the workaround code in that script:
# GCC uses paths such as lib/../lib64, so make sure lib
# directories always exist.
mkdir_cmd = ['mkdir', '-p',
os.path.join(policy.installdir, 'lib')]
if policy.use_usr:
mkdir_cmd += [os.path.join(policy.installdir, 'usr', 'lib')]
cmdlist.add_command('mkdir-lib', mkdir_cmd)
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 --- Comment #37 from Peter Bergner --- (In reply to Kewen Lin from comment #36) > Mike had one patch [1] under review for the power8 fusion piece, moving this > under his name. Thanks Mike! > > [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591496.html Pinged a 5th time here: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593943.html
[Bug gcov-profile/105210] gcc/auto-profile.cc:391:11: warning: variable 'level' set but not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105210 --- Comment #11 from Martin Liška --- > Presumably there's a good reason why the one in file > libdecnumber/dpd/decimal64.c > didn't get fixed ? It's pretty legacy code out of gcc folder, so that's the reason ;)
[Bug testsuite/105498] New: new test case gcc/testsuite/c-c++-common/Wconversion-1.c from r13-122-g1cd3faf5dddb3c has unexpected errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105498 Bug ID: 105498 Summary: new test case gcc/testsuite/c-c++-common/Wconversion-1.c from r13-122-g1cd3faf5dddb3c has unexpected errors Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:1cd3faf5dddb3cbfa2ed308ecf3db4f70bff337e, r13-122-g1cd3faf5dddb3c make -k check-gcc RUNTESTFLAGS="dg.exp=gcc/testsuite/c-c++-common/Wconversion-1.c" # of unexpected failures1 FAIL: c-c++-common/Wconversion-1.c -Wc++-compat (test for warnings, line 13) # of unexpected failures4 FAIL: c-c++-common/Wconversion-1.c -std=gnu++98 (test for warnings, line 13) FAIL: c-c++-common/Wconversion-1.c -std=gnu++14 (test for warnings, line 13) FAIL: c-c++-common/Wconversion-1.c -std=gnu++17 (test for warnings, line 13) FAIL: c-c++-common/Wconversion-1.c -std=gnu++20 (test for warnings, line 13) commit 1cd3faf5dddb3cbfa2ed308ecf3db4f70bff337e (HEAD, refs/bisect/bad) Author: Marek Polacek Date: Wed Mar 30 16:59:33 2022 -0400 c-family: Tweak -Woverflow diagnostic
[Bug testsuite/105498] new test case gcc/testsuite/c-c++-common/Wconversion-1.c from r13-122-g1cd3faf5dddb3c has unexpected errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105498 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Keywords||patch Last reconfirmed||2022-05-05 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Patch was posted: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594091.html
[Bug c++/64679] Spurious redefinition error when parsing not-quite-most-vexing-parse declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64679
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:ee9128189623ce43343ce326caa8d5eec2eccfec
commit r13-146-gee9128189623ce43343ce326caa8d5eec2eccfec
Author: Marek Polacek
Date: Tue May 3 19:01:19 2022 -0400
c++: wrong error with MVP and pushdecl [PR64679]
This patch fixes the second half of 64679. Here we issue a wrong
"redefinition of 'int x'" for the following:
struct Bar {
Bar(int, int, int);
};
int x = 1;
Bar bar(int(x), int(x), int{x}); // #1
cp_parser_parameter_declaration_list does pushdecl every time it sees
a named parameter, so the second "int(x)" causes the error. That's
premature, since this turns out to be a constructor call after the
third argument!
If the first parameter is parenthesized, we can't push until we've
established we're looking at a function declaration. Therefore this
could be fixed by some kind of lookahead. I thought about introducing a
lightweight variant of cp_parser_parameter_declaration_list that would
not have any side effects and would return as soon as it figures out
whether it's looking at a declaration or expression. Since that would
require fairly nontrivial changes, I wanted something simpler.
Something like delaying the pushdecl until we've reached the ')'
following the parameter-declaration-clause. But we must push the
parameters before processing a default argument, as in:
Bar bar(int(a), int(b), int c = sizeof(a)); // valid
Moreover, this code should still be accepted
Bar f(int(i), decltype(i) j = 42);
so this patch stashes parameters into a vector when parsing tentatively
only when pushdecl-ing a parameter would result in a clash and an error
about redefinition/redeclaration. The stashed parameters are pushed at
the end of a parameter-declaration-clause if it's followed by a ')', so
that we still diagnose redefining a parameter.
PR c++/64679
gcc/cp/ChangeLog:
* parser.cc (cp_parser_parameter_declaration_clause): Maintain
a vector of parameters that haven't been pushed yet. Push them at
the
end of a valid parameter-declaration-clause.
(cp_parser_parameter_declaration_list): Take a new auto_vec
parameter.
Do not pushdecl while parsing tentatively when pushdecl-ing a
parameter
would result in a hard error.
(cp_parser_cache_defarg): Adjust the call to
cp_parser_parameter_declaration_list.
gcc/testsuite/ChangeLog:
* g++.dg/parse/ambig11.C: New test.
* g++.dg/parse/ambig12.C: New test.
* g++.dg/parse/ambig13.C: New test.
* g++.dg/parse/ambig14.C: New test.
[Bug c++/64679] Spurious redefinition error when parsing not-quite-most-vexing-parse declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64679 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed for GCC 13.
[Bug c++/105499] New: inconsistency between -Werror=c++-compat and g++ in __extension__ block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105499
Bug ID: 105499
Summary: inconsistency between -Werror=c++-compat and g++ in
__extension__ block
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider
int *f (void *q)
{
return __extension__ ({ int *p = q; p; });
}
With GCC 11.3.0 under Debian (Debian package), I get the following:
$ gcc -Werror=c++-compat -c tst.c
$ g++ -c tst.c
tst.c: In function ‘int* f(void*)’:
tst.c:3:36: error: invalid conversion from ‘void*’ to ‘int*’ [-fpermissive]
3 | return __extension__ ({ int *p = q; p; });
|^
||
|void*
so no errors with "gcc -Werror=c++-compat", but an error with g++. This is not
consistent. Either this is regarded as a valid extension in C++ so that both
should succeed, or this is not valid C++ code even in __extension__ so that
both should fail.
Same issue with various GCC versions from 4.9 to 11.3.0.
AFAIK, the purpose of -Wc++-compat is to test whether code would still pass
when replacing C compilation by C++ (there might be false positives or false
negatives, but this should not be the case with the above example).
FYI, I got the above issue while testing GNU MPFR (tested with
-Werror=c++-compat first, and with g++ a bit later in a more extensive test).
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #4 from Jerry DeLisle --- Hi all, I will be looking closer on this one. As I said have to look at the checking code. As soon as I noticed -std=f2003 allowing this it makes no sense at all. I can understand possibly the extension to allow a semicolon to simply end the transfer. We do need to fix the diagnostics. I see I no longer have change status on PRs. Evidently some of the address and login changes I have had to do in the process of changing my email providers has messed it all up. Who do you call? Ghost Busters?
[Bug libfortran/105361] Incorrect end-of-file condition for derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle2 at gmail dot com --- Comment #3 from Jerry DeLisle --- Hi Thomas, this is another one I would like to look at since I implemented a lot of this in the beginning. I want to look at the dump and see why the condition is not being set. I have a hunch on this. It has to do with the DTP structure where the status kept.
[Bug target/105493] [12/13 Regression] x86_64 538.imagick_r 6% regressions and 2% 525.x264_r regressions on Alder Lake after r12-7319-g90d693bdc9d718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105493 --- Comment #2 from cuilili --- (In reply to Richard Biener from comment #1) > Martin is currently re-benchmarking GCC 12 on AMD, so let's see if there's > anything left on those. AMD may not have this issue, Richard fixed AMD regression with this commit r12-7612-g69619acd8d9b5856f5af6e5323d9c7c4ec9ad08f, but intel wasn't fixed because they use different costs.
[Bug gcov-profile/105500] New: [Gcov]wrong freqency for the while loop with struct in the expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105500
Bug ID: 105500
Summary: [Gcov]wrong freqency for the while loop with struct in
the expression
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ cat small.c
struct S { int f; } a;
struct S foo (int x, struct S y)
{
int b = y.f;
return a;
}
void bar ()
{
while (a.f)
{
struct S c = {0};
foo (0, c);
}
}
int main ()
{
bar ();
return 0;
}
$ gcc -O0 --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:54.55% of 11
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:struct S { int f; } a;
-:2:
#:3:struct S foo (int x, struct S y)
-:4:{
#:5: int b = y.f;
#:6: return a;
-:7:}
-:8:
1:9:void bar ()
-: 10:{
2: 11: while (a.f)
-: 12:{
#: 13: struct S c = {0};
#: 14: foo (0, c);
-: 15:}
1: 16:}
-: 17:
1: 18:int main ()
-: 19:{
1: 20: bar ();
1: 21: return 0;
-: 22:}
Line #11 is wrongly marked as executed twice which should be executed once.
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 --- Comment #18 from Mattias Ellert --- If the additional symbols are undesirable, using the workaround proposed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336#c1 is an alternative. This silences the warning without adding additional symbols. This proposed change is similar to the change introduced a few lines further up in the same file in the following commit: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e14ea108faa6eba6a60a45ff0ca3099ce6ae45c2 This change was introduced to fix a similar false positive warning in GCC 11.
[Bug c++/105499] inconsistency between -Werror=c++-compat and g++ in __extension__ block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105499 Eric Gallager changed: What|Removed |Added Keywords||diagnostic See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=71003, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=87274 CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- This is probably another one of those issues with how the preprocessor works in C++ mode in general; see for example bug 71003 and bug 87274
[Bug target/105496] Comparison optimizations result in unnecessary cmp instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105496
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Keywords||missed-optimization
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-05-06
Version|unknown |12.0
--- Comment #1 from Richard Biener ---
Confirmed. We canonicalize x < 11 to x <= 10 and on GIMPLE we don't have CC
flags and thus we cannot combine the two compares (we could maybe invent
switch (x CC_EXPR 11) { case LT: .. }). So _maybe_ compare elimination on RTL
is needed to do the job here.
[Bug gcov-profile/105500] [Gcov]wrong freqency for the while loop with struct in the expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105500 Richard Biener changed: What|Removed |Added Known to fail||11.3.1, 7.5.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-05-06 --- Comment #1 from Richard Biener --- Confirmed.
