[Bug target/105338] [12 Regression] Regression: jump or cmove generated for pattern (x ? CST : 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105338
--- Comment #13 from denis.campredon at gmail dot com ---
Thanks a lots.
I have a question though: foo and bar are similar, foo produces a branchless
code whereas bar uses a jump.
int foo(int i) {
return !i ? 0 : -2;
}
int bar(int i) {
return i ? -2 : 0;
}
If I'm readding correctly in the two functions the probabilities are the same.
Is this "normal" or worth a new ticket ?
[Bug c++/102629] [10/11/12 Regression] ICE: tree check in lookup_base, at cp/search.c:233 since r10-2194-g10acaf4db9f8b54b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102629 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/104624] [10/11/12 Regression] ICE in standard_conversion, at cp/call.cc:1213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104624 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:65735d21ac410463126114c572999682f987972c commit r12-8258-g65735d21ac410463126114c572999682f987972c Author: Jason Merrill Date: Thu Apr 21 17:24:07 2022 -0400 c++: generic lambda fn parm pack [PR104624] Parameter packs from the enclosing context can be used unexpanded in a lambda that is itself part of a pack expansion, but not packs that are part of the lambda itself. We already check for capture packs; we also need to check for function parameter packs of the lambda call operator. PR c++/104624 gcc/cp/ChangeLog: * pt.cc (check_for_bare_parameter_packs): Check for lambda function parameter pack. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/lambda-generic-variadic22.C: New test.
[Bug c++/104624] [10/11/12 Regression] ICE in standard_conversion, at cp/call.cc:1213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104624 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org
[Bug c++/105304] [10/11 Regression] ICE segfault using ad-hoc concept with -Wall since r10-7441-ga7ea3d2ced786c45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105304 Patrick Palka changed: What|Removed |Added Summary|[10/11/12 Regression] ICE |[10/11 Regression] ICE |segfault using ad-hoc |segfault using ad-hoc |concept with -Wall since|concept with -Wall since |r10-7441-ga7ea3d2ced786c45 |r10-7441-ga7ea3d2ced786c45 --- Comment #3 from Patrick Palka --- Fixed for GCC 12 so far.
[Bug c++/105304] [10/11/12 Regression] ICE segfault using ad-hoc concept with -Wall since r10-7441-ga7ea3d2ced786c45
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105304 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c83b9c54d9dee2dce5d8268472a745b013d166cc commit r12-8257-gc83b9c54d9dee2dce5d8268472a745b013d166cc Author: Patrick Palka Date: Mon Apr 25 21:49:00 2022 -0400 c++: ICE with requires-expr and -Wsequence-point [PR105304] Here we're crashing from verify_sequence_points for this requires-expr condition because it contains a templated CAST_EXPR with empty operand, and verify_tree doesn't ignore this empty operand only because the manual tail recursion that it performs for unary expression trees skips the NULL test. PR c++/105304 gcc/c-family/ChangeLog: * c-common.cc (verify_tree) [restart]: Move up to before the NULL test. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires30.C: New test.
[Bug c++/105289] [11/12 Regression] ICE on partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105289 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:288e4c64f6b4806358aabc9b99b2fba72bf04bf6 commit r12-8256-g288e4c64f6b4806358aabc9b99b2fba72bf04bf6 Author: Patrick Palka Date: Mon Apr 25 21:46:56 2022 -0400 c++: partial ordering with dependent NTTP type [PR105289] Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing on (respectively) two testcases that we used to accept in C++17 mode since r8-1437-g3da557ec145823. Both testcases declare a partial specialization of a primary template that has an NTTP with dependent type, and the validity of these partial specializations is unclear and the subject of PR86193 / CWG 455. So for now, this minimal patch just aims to fix the crash in the second testcase. During deduction, when checking whether the type of an NTTP uses still-undeduced parameters, we were incorrectly substituting into the previously substituted type instead of into its original type. In passing this patch also downgrades the "not more specialized" diagnostic from a permerror to a pedwarn. PR c++/105289 PR c++/86193 gcc/cp/ChangeLog: * pt.cc (process_partial_specialization): Downgrade "partial specialization isn't more specialized" diagnostic from permerror to an on-by-default pedwarn. (unify) : When substituting into the NTTP type a second time, use the original type not the substituted type. gcc/testsuite/ChangeLog: * g++.dg/template/partial-specialization11.C: New test. * g++.dg/template/partial-specialization12.C: New test.
[Bug c++/86193] [DR455] Partial ordering of non-type template parameters with dependent types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86193 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:288e4c64f6b4806358aabc9b99b2fba72bf04bf6 commit r12-8256-g288e4c64f6b4806358aabc9b99b2fba72bf04bf6 Author: Patrick Palka Date: Mon Apr 25 21:46:56 2022 -0400 c++: partial ordering with dependent NTTP type [PR105289] Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing on (respectively) two testcases that we used to accept in C++17 mode since r8-1437-g3da557ec145823. Both testcases declare a partial specialization of a primary template that has an NTTP with dependent type, and the validity of these partial specializations is unclear and the subject of PR86193 / CWG 455. So for now, this minimal patch just aims to fix the crash in the second testcase. During deduction, when checking whether the type of an NTTP uses still-undeduced parameters, we were incorrectly substituting into the previously substituted type instead of into its original type. In passing this patch also downgrades the "not more specialized" diagnostic from a permerror to a pedwarn. PR c++/105289 PR c++/86193 gcc/cp/ChangeLog: * pt.cc (process_partial_specialization): Downgrade "partial specialization isn't more specialized" diagnostic from permerror to an on-by-default pedwarn. (unify) : When substituting into the NTTP type a second time, use the original type not the substituted type. gcc/testsuite/ChangeLog: * g++.dg/template/partial-specialization11.C: New test. * g++.dg/template/partial-specialization12.C: New test.
[Bug c++/105386] New: Tuple in unevaluated context is instantiated; creates reference to void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105386
Bug ID: 105386
Summary: Tuple in unevaluated context is instantiated; creates
reference to void
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: cuzdav at gmail dot com
Target Milestone: ---
Created attachment 52878
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52878=edit
preprocessed code
Starting with g++11.2 some of meta-programming code started to fail.
While instantiating a tuple in an unevaluated context, it now complains that
the tuple contains a void member and it's creating a reference to void, yet it
is the same type as in the working case, just computed differently.
Output of g++ -v
(base) bash-4.2$ /opt/imc/gcc-11.2.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/opt/imc/gcc-11.2.0/bin/g++
COLLECT_LTO_WRAPPER=/opt/imc/gcc-11.2.0/libexec/gcc/x86_64-pc-linux-gnu/11.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-11.2.0/configure --prefix=/opt/imc/gcc-11.2.0
--enable-languages=c,c++,fortran,lto --disable-multilib
--with-build-time-tools=/opt/buildagent/work/d7a993299378ca7e/11.2.0/INSTALLDIR//opt/imc/gcc-11.2.0/bin
--enable-libstdcxx-time=rt
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (GCC)
Code appears in its entirety in attachment, but here is the main focus of the
error:
class Chunk { };
using ChunkMetaData = std::tuple;
template ChunkMetaData chunkMetaData(MessageT&&);
template
class ChunkSeq
{
public:
using good_type = ChunkMetaData;
#ifdef SHOWBUG
using bad_type = decltype(chunkMetaData(std::declval()));
static_assert(std::is_same_v);
using MetaData = bad_type;
#else
using MetaData = good_type;
#endif
In gcc10, when SHOWBUG is defined, it still builds. The static assertion
passes. With gcc11 and 12, it fails, upset about a tuple creating a reference
to void.
Live example:
https://godbolt.org/z/4Wq3s936W
Errors:
In file included from krx/feed/sr10/foo.cpp:1:
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:
In instantiation of ‘struct std::_Head_base<2, void, false>’:
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:407:12:
required from ‘struct std::_Tuple_impl<2, void>’
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:244:12:
required from ‘struct std::_Tuple_impl<0, void, Chunk, void>’
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:599:11:
required from ‘class std::tuple’
krx/feed/sr10/foo.cpp:171:42: [ skipping 2 instantiation contexts, use
-ftemplate-backtrace-limit=0 to disable ]
krx/feed/sr10/foo.cpp:111:57: required from ‘constexpr const bool
InvertPredicate >::value >’
krx/feed/sr10/foo.cpp:122:11: required from ‘struct
RemoveIfImpl >,
std::tuple, PartialField<1> > >’
krx/feed/sr10/foo.cpp:235:7: required by substitution of ‘template
using PartialStartField = typename KeepIf, typename
RemoveIfImpl >,
std::tuple, PartialField<1> > >::type>::type [with T = Chunk]’
krx/feed/sr10/foo.cpp:240:47: required from ‘constexpr const bool
HasPartialBegin::value’
krx/feed/sr10/foo.cpp:111:57: required from ‘constexpr const bool
InvertPredicate::value’
krx/feed/sr10/foo.cpp:122:11: required from ‘struct
RemoveIfImpl, std::tuple >’
krx/feed/sr10/foo.cpp:247:6: required from here
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:182:17:
error: forming reference to void
182 | constexpr _Head_base(const _Head& __h)
| ^~
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:219:7:
error: forming reference to void
219 | _M_head(_Head_base& __b) noexcept { return __b._M_head_impl; }
| ^~~
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:222:7:
error: forming reference to void
222 | _M_head(const _Head_base& __b) noexcept { return
__b._M_head_impl; }
| ^~~
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:224:13:
error: ‘std::_Head_base<_Idx, _Head, false>::_M_head_impl’ has incomplete type
224 | _Head _M_head_impl;
| ^~~~
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:224:13:
error: invalid use of ‘void’
In file included from krx/feed/sr10/foo.cpp:1:
/opt/imc/gcc-11.2.0/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../include/c++/11.2.0/tuple:
In instantiation of ‘struct std::_Tuple_impl<2, void>’:
[Bug rtl-optimization/105314] [12 Regression] ifcvt regression in noce_try_store_flag_mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105314 --- Comment #8 from Christoph Müllner --- Yes, I was wrong in my previous comment. Jakub's patch is of course right. The transformation in noce_try_store_flag_mask() does: x = cond ? 0 else b // b may be x ==> target = cond ? 0 : -1; // seqz & neg x = target & b; // and I was misled by the comment above the function, which only shows the special case when b equals x. Probably this is a better comment: /* Convert "if (test) x = 0 else x = y;" to "x = -(test == 0) & y;" */
[Bug analyzer/104308] no location info provided for [-Wanalyzer-use-of-uninitialized-value] warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #12 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/105366] [11 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer since r11-4511-gf635f0ce87d687b1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105366 David Malcolm changed: What|Removed |Added Summary|[11/12 Regression] ICE: in |[11 Regression] ICE: in |cmp_cst, at |cmp_cst, at |analyzer/svalue.cc:309 with |analyzer/svalue.cc:309 with |-O -fanalyzer since |-O -fanalyzer since |r11-4511-gf635f0ce87d687b1 |r11-4511-gf635f0ce87d687b1 --- Comment #4 from David Malcolm --- Should be fixed for gcc 12 by the above commit. Keeping open for backporting to gcc 11.
[Bug analyzer/105365] [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -fanalyzer since r12-2337-g33255ad3ac14e395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105365 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Should be fixed for gcc 12 by the above commit.
[Bug analyzer/105365] [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -fanalyzer since r12-2337-g33255ad3ac14e395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105365 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:6ad3ca0077ec0d5f740cef5fdb743ffb61575941 commit r12-8254-g6ad3ca0077ec0d5f740cef5fdb743ffb61575941 Author: David Malcolm Date: Mon Apr 25 19:36:37 2022 -0400 analyzer: fix ICEs on complex constants [PR105365,105366] gcc/analyzer/ChangeLog: PR analyzer/105365 PR analyzer/105366 * svalue.cc (cmp_cst): Rename to... (cmp_csts_same_type): ...this. Convert all recursive calls to calls to... (cmp_csts_and_types): this new function. (svalue::cmp_ptr): Update for renaming of cmp_cst gcc/testsuite/ChangeLog: PR analyzer/105365 PR analyzer/105366 * gcc.dg/analyzer/pr105365.c: New test. * gcc.dg/analyzer/pr105366.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/105366] [11/12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer since r11-4511-gf635f0ce87d687b1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105366 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:6ad3ca0077ec0d5f740cef5fdb743ffb61575941 commit r12-8254-g6ad3ca0077ec0d5f740cef5fdb743ffb61575941 Author: David Malcolm Date: Mon Apr 25 19:36:37 2022 -0400 analyzer: fix ICEs on complex constants [PR105365,105366] gcc/analyzer/ChangeLog: PR analyzer/105365 PR analyzer/105366 * svalue.cc (cmp_cst): Rename to... (cmp_csts_same_type): ...this. Convert all recursive calls to calls to... (cmp_csts_and_types): this new function. (svalue::cmp_ptr): Update for renaming of cmp_cst gcc/testsuite/ChangeLog: PR analyzer/105365 PR analyzer/105366 * gcc.dg/analyzer/pr105365.c: New test. * gcc.dg/analyzer/pr105366.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/104308] no location info provided for [-Wanalyzer-use-of-uninitialized-value] warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104308 --- Comment #11 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:a5dc2641add6b4f54086d40ae706fda3cdaac7f5 commit r12-8253-ga5dc2641add6b4f54086d40ae706fda3cdaac7f5 Author: David Malcolm Date: Mon Apr 25 19:34:33 2022 -0400 gimple-fold: fix further missing stmt locations [PR104308] PR analyzer/104308 initially reported about a -Wanalyzer-use-of-uninitialized-value diagnostic using UNKNOWN_LOCATION when complaining about certain memmove operations where the source is uninitialized. In r12-7856-g875342766d4298 I fixed the missing location for a stmt generated by gimple_fold_builtin_memory_op, but the reporter then found another way to generate such a stmt with UNKNOWN_LOCATION. I've now gone through gimple_fold_builtin_memory_op looking at all statement creation, and found three places in which a new statement doesn't have a location set on it (either directly via gimple_set_location, or indirectly via gsi_replace), one of which is the new reproducer. This patch adds a gimple_set_location to these three cases, and adds test coverage for one of them (the third hunk within the patch), fixing the new reproducer for PR analyzer/104308. gcc/ChangeLog: PR analyzer/104308 * gimple-fold.cc (gimple_fold_builtin_memory_op): Explicitly set the location of new_stmt in all places that don't already set it, whether explicitly, or via a call to gsi_replace. gcc/testsuite/ChangeLog: PR analyzer/104308 * gcc.dg/analyzer/pr104308.c: Add test coverage. Signed-off-by: David Malcolm
[Bug rtl-optimization/105314] [12 Regression] ifcvt regression in noce_try_store_flag_mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105314
--- Comment #7 from ptomsich at gcc dot gnu.org ---
The transformation for
"""
long func2 (long a, long b, long c)
{
if (c)
a = 0;
else
a = 5;
return a;
}
"""
into
"""
0006 :
6: 00163513seqza0,a2
a: 40a00533neg a0,a0
e: 8915andia0,a0,5
10: 8082ret
"""
is correct, as we get
"""
tmp = c ? 0 : -1;
a = tmp & 5;
"""
[Bug c++/100252] [9/10/11/12 Regression] Internal compiler error during template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100252
--- Comment #8 from Marek Polacek ---
This is tricky, because we end up with
{.x=(&)->x, .y=(&)->x}
that is, two PLACEHOLDER_EXPRs for different types on the same level in one {
}, so our CONSTRUCTOR_PLACEHOLDER_BOUNDARY mechanism to avoid replacing
unrelated PLACEHOLDER_EXPRs will not work.
[Bug rtl-optimization/105314] [12 Regression] ifcvt regression in noce_try_store_flag_mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105314
--- Comment #6 from Christoph Müllner ---
The proposed fix is triggering an invalid transformation.
The pattern we need to transform is:
Convert "if (test) x = 0;" to "x &= -(test == 0);"
If there is an else branch, we can't apply the transformation.
Error case:
"""
long func2 (long a, long b, long c) // should not be optimized
{
if (c)
a = 0;
else
a = 5;
return a;
}
"""
With the patch this gets compiled to:
0006 :
6: 00163513seqza0,a2
a: 40a00533neg a0,a0
e: 8915andia0,a0,5
10: 8082ret
[Bug rtl-optimization/105314] [12 Regression] ifcvt regression in noce_try_store_flag_mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105314 --- Comment #5 from ptomsich at gcc dot gnu.org --- The fix addresses the issue and generates no new failures on small test cases. Testing against SPEC is still ongoing and I'll report back once that has completed.
[Bug tree-optimization/105329] Bogus restrict warning when assigning 1-char string literal to std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 Mattias Ellert changed: What|Removed |Added CC||mattias.ellert at physics dot uu.s ||e --- Comment #6 from Mattias Ellert --- This is a duplicate of bug #104336.
[Bug libgomp/105358] [12 Regression] scan* fails on targets without aligned memory allocators.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105358 --- Comment #9 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #8) > Created attachment 52865 [details] > gcc12-pr105358.patch > > So what about this? All the newly added comparisons should fold into true > or false at compile time. Thanks, this works for me (tested two 32b hosts and one x86_64 one).
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 Segher Boessenkool changed: What|Removed |Added Attachment #52871|0 |1 is obsolete|| --- Comment #16 from Segher Boessenkool --- Created attachment 52877 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52877=edit proposed patch Bah. I did everything wrong you can do wrong here, it seems :-/
[Bug preprocessor/105362] Improvement: diagnose undefined behavior in preprocessing directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105362
--- Comment #2 from Pavel M ---
I do believe that evaluation of constant expressions in conditional inclusion
is done according to the rules of constant expressions ("except that ...", see
C11, 6.10.1/1). Hence, I expect the same diagnostics in all the places where
constant expressions may be used.
[Bug fortran/105381] [12 Regression] Memory-hog since r12-8230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105381 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org
[Bug fortran/105381] [12 Regression] Memory-hog since r12-8230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105381 --- Comment #1 from Mikael Morin --- Draft patch. diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc index e4b6270ccf8..e0070aa080d 100644 --- a/gcc/fortran/trans-array.cc +++ b/gcc/fortran/trans-array.cc @@ -3698,7 +3698,8 @@ non_negative_strides_array_p (tree expr) if (DECL_P (expr) && DECL_LANG_SPECIFIC (expr)) if (tree orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr)) - return non_negative_strides_array_p (orig_decl); + if (orig_decl != expr) + return non_negative_strides_array_p (orig_decl); return true; }
[Bug fortran/105379] [12 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered since r12-8235-gfa5cd7102da676dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105379 --- Comment #3 from Mikael Morin --- Created attachment 52876 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52876=edit Draft patch This shows no testsuite regression. But there is something that I want to check before submitting it tomorrow.
[Bug fortran/104717] [9/10/11/12 Regression] ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104717 --- Comment #9 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:b2202431910e30d8505c94d1cb9341cac7080d10 commit r12-8252-gb2202431910e30d8505c94d1cb9341cac7080d10 Author: Jakub Jelinek Date: Wed Apr 20 19:06:17 2022 +0200 fortran: Fix up gfc_trans_oacc_construct [PR104717] So that move_sese_region_to_fn works properly, OpenMP/OpenACC constructs for which that function is invoked need an extra artificial BIND_EXPR around their body so that we move all variables of the bodies. The C/C++ FEs do that both for OpenMP constructs like OMP_PARALLEL, OMP_TASK or OMP_TARGET and for OpenACC constructs that behave similarly to OMP_TARGET, but the Fortran FE only does that for OpenMP constructs. The following patch does that for OpenACC constructs too. PR fortran/104717 gcc/fortran/ * trans-openmp.cc (gfc_trans_oacc_construct): Wrap construct body in an extra BIND_EXPR. gcc/testsuite/ * gfortran.dg/goacc/pr104717.f90: New test. * gfortran.dg/goacc/privatization-1-compute-loop.f90: Adjust. libgomp/ * testsuite/libgomp.oacc-fortran/privatized-ref-2.f90: Adjust. Co-authored-by: Thomas Schwinge
[Bug middle-end/103993] -Wismatched-new-delete due to difference in inlining decisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103993
andre at kostur dot net changed:
What|Removed |Added
CC||andre at kostur dot net
--- Comment #3 from andre at kostur dot net ---
Here's a smaller, minimal example of the issue (as described in the subject):
#include
struct Foo {
static void * operator new( size_t s ) __attribute__( ( noinline ) ) {
return ::operator new( s );
}
static void operator delete( void * p ) { return ::operator delete( p ); }
};
int
main() {
Foo * f = new Foo();
delete f;
}
[Bug tree-optimization/105385] ICE: Aborted (in do_mpfr_arg2): GNU MP: Cannot allocate memory (size=3458764513820540832) with __builtin_jn{, f, l}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105385 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-04-25 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Confirmed: Program received signal SIGABRT, Aborted. __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 44return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0; (gdb) bt #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x779081e3 in __pthread_kill_internal (signo=6, threadid=) at pthread_kill.c:78 #2 0x778b8306 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x778a1813 in __GI_abort () at abort.c:79 #4 0x77c3cd47 in __gmp_default_allocate (size=3458764513820540832) at /usr/src/debug/gmp-6.2.1-4.5.x86_64/memory.c:57 #5 __gmp_default_allocate (size=3458764513820540832) at /usr/src/debug/gmp-6.2.1-4.5.x86_64/memory.c:46 #6 0x77ce98a1 in mpfr_allocate_func (alloc_size=3458764513820540832) at /usr/src/debug/mpfr-4.1.0-2.18.x86_64/src/mpfr-gmp.c:315 #7 0x77d26838 in mpfr_jn (res=0x7fffc460, n=-2345192, z=0x7fffc460, r=MPFR_RNDN) at /usr/src/debug/mpfr-4.1.0-2.18.x86_64/src/jn.c:245 #8 0x00bd73ba in do_mpfr_arg2 (result=result@entry=0x7fffc530, func=0x77d264c0 , arg0=..., arg1=arg1@entry=0x777592a0, format=format@entry=0x2785c40 ) at /home/marxin/Programming/gcc/gcc/fold-const-call.cc:232 #9 0x00bd9aab in do_mpfr_arg2 (format=0x2785c40 , arg1=0x777592a0, arg0=..., func=, result=0x7fffc530) at /home/marxin/Programming/gcc/gcc/fold-const-call.cc:222 #10 fold_const_call_sss (format=0x2785c40 , arg1=0x777592a0, arg0=..., fn=CFN_BUILT_IN_JN, result=0x7fffc530) at /home/marxin/Programming/gcc/gcc/fold-const-call.cc:1462 #11 fold_const_call_1 (fn=CFN_BUILT_IN_JN, type=0x7762f348, arg0=0x77756450, arg1=) at /home/marxin/Programming/gcc/gcc/fold-const-call.cc:1562 with: Name : mpfr-devel Version: 4.1.0-2.18
[Bug tree-optimization/105384] compilation never (?) finishes with __builtin_yn{,f,l} at -O and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105384 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-04-25 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- I can confirm that with system libraries (likely latest releases).
[Bug target/105383] [11/12 Regression] ICE: in change_insns, at rtl-ssa/changes.cc:674 with -Os -fno-tree-dominator-opts -fno-tree-vrp -msseregparm -m32 since r11-6188-g0b76990a9d75d97b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105383 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Status|UNCONFIRMED |NEW Summary|[11/12 Regression] ICE: in |[11/12 Regression] ICE: in |change_insns, at|change_insns, at |rtl-ssa/changes.cc:674 with |rtl-ssa/changes.cc:674 with |-Os |-Os |-fno-tree-dominator-opts|-fno-tree-dominator-opts |-fno-tree-vrp -msseregparm |-fno-tree-vrp -msseregparm |-m32|-m32 since ||r11-6188-g0b76990a9d75d97b Last reconfirmed||2022-04-25 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r11-6188-g0b76990a9d75d97b.
[Bug fortran/105381] [12 Regression] Memory-hog since r12-8230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105381 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-04-25 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug fortran/105380] [PDT] ICE in gfc_conv_array_initializer, at fortran/trans-array.cc:6317 since r8-3056-g5bab4c9631c478b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105380 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-04-25 Summary|[PDT] ICE in|[PDT] ICE in |gfc_conv_array_initializer, |gfc_conv_array_initializer, |at |at |fortran/trans-array.cc:6317 |fortran/trans-array.cc:6317 ||since ||r8-3056-g5bab4c9631c478b7 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r8-3056-g5bab4c9631c478b7.
[Bug fortran/105379] [12 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered since r12-8235-gfa5cd7102da676dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105379 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Summary|[12 Regression] ICE in |[12 Regression] ICE in |gfc_compare_array_spec(): |gfc_compare_array_spec(): |Array spec clobbered|Array spec clobbered since ||r12-8235-gfa5cd7102da676dc --- Comment #2 from Martin Liška --- (In reply to Mikael Morin from comment #1) > Caused by r12-8235-gfa5cd7102da676dcb1757b1288421f5f3439ae0e, I guess. > So I am the culprit. Yes, I can confirm that.
[Bug tree-optimization/104336] bogus -Wrestrict for std::string assignment with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #2 from Andrew Macleod --- Huh. This looks earily familiar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 as well. That PR documents why the code sequence isn't handled well by the optimizers in this release... we improve analysis on the length calculation, but not on the pointer side... so we leave dead code that the warning system complains about. Presumably this would also fix that?
[Bug c++/105377] Likely a misleading clang warning -Wc++20-attribute-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Martin Liška --- (In reply to Jakub Jelinek from comment #1) > Yes, it is an extension, but if the compiler doesn't recognize it, it > shouldn't do anything with it. So it is just fine to use it... I agree with that and I'm going to silente the warning in contrib/filter-clang-warnings.py.
[Bug tree-optimization/105384] compilation never (?) finishes with __builtin_yn{,f,l} at -O and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105384 --- Comment #3 from Zdenek Sojka --- (In reply to Andrew Pinski from comment #2) > Can you try the one that is downloaded via contrib/download_pre*. The you for the comment. The versions I am using are: [ebuild R] dev-libs/gmp-6.2.1-r2 [ebuild R] dev-libs/mpfr-4.1.0_p13-r1 [ebuild R] dev-libs/isl-0.24-r2 [ebuild R] dev-libs/mpc-1.2.1 They match the version downloaded by contrib/download_pre*, but might contain gentoo-specific patches: gmp-6.2.1.tar.bz2: OK mpfr-4.1.0.tar.bz2: OK mpc-1.2.1.tar.gz: OK isl-0.24.tar.bz2: OK I will try with the vanilla versions.
[Bug tree-optimization/105384] compilation never (?) finishes with __builtin_yn{,f,l} at -O and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105384 --- Comment #2 from Andrew Pinski --- Can you try the one that is downloaded via contrib/download_pre*.
[Bug tree-optimization/105385] New: ICE: Aborted (in do_mpfr_arg2): GNU MP: Cannot allocate memory (size=3458764513820540832) with __builtin_jn{,f,l}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105385
Bug ID: 105385
Summary: ICE: Aborted (in do_mpfr_arg2): GNU MP: Cannot
allocate memory (size=3458764513820540832) with
__builtin_jn{,f,l}
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Created attachment 52875
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52875=edit
reduced testcase
I don't know if this should be reported against gcc or libmpfr.
Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c
GNU MP: Cannot allocate memory (size=3458764513820540832)
testcase.c: In function 'foo':
testcase.c:4:3: internal compiler error: Aborted
4 | __builtin_jn (4292622104, 0xff00ff00ff00ff00);
| ^~~~
0x13a3dff crash_signal
/repo/gcc-trunk/gcc/toplev.cc:322
0x100fe49 do_mpfr_arg2
/repo/gcc-trunk/gcc/fold-const-call.cc:232
0x1012295 do_mpfr_arg2
/repo/gcc-trunk/gcc/fold-const-call.cc:222
0x1012295 fold_const_call_sss
/repo/gcc-trunk/gcc/fold-const-call.cc:1462
0x1012295 fold_const_call_1
/repo/gcc-trunk/gcc/fold-const-call.cc:1562
0xe4ab9a fold_builtin_2
/repo/gcc-trunk/gcc/builtins.cc:9376
0xe4ab9a fold_builtin_n
/repo/gcc-trunk/gcc/builtins.cc:9540
0xfdcf3a fold_build_call_array_loc(unsigned int, tree_node*, tree_node*, int,
tree_node**)
/repo/gcc-trunk/gcc/fold-const.cc:13965
0xd52b3f build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*, tree_node*)
/repo/gcc-trunk/gcc/c/c-typeck.cc:3217
0xd74093 c_parser_postfix_expression_after_primary
/repo/gcc-trunk/gcc/c/c-parser.cc:10561
0xd6b3e0 c_parser_postfix_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:10234
0xd6f8ea c_parser_unary_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:8261
0xd71081 c_parser_cast_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:8103
0xd712ee c_parser_binary_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:7906
0xd7277b c_parser_conditional_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:7606
0xd72fa0 c_parser_expr_no_commas
/repo/gcc-trunk/gcc/c/c-parser.cc:7521
0xd73211 c_parser_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:10697
0xd73978 c_parser_expression_conv
/repo/gcc-trunk/gcc/c/c-parser.cc:10736
0xd68957 c_parser_statement_after_labels
/repo/gcc-trunk/gcc/c/c-parser.cc:6263
0xd6af3a c_parser_compound_statement_nostart
/repo/gcc-trunk/gcc/c/c-parser.cc:5800
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/105384] compilation never (?) finishes with __builtin_yn{,f,l} at -O and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105384 --- Comment #1 from Andrew Pinski --- What version of gmp, mpfr are you using?
[Bug tree-optimization/105384] New: compilation never (?) finishes with __builtin_yn{,f,l} at -O and above
fndef (parser=0x776f7b40, fndef_ok=, static_assert_ok=, empty_ok=, nested=, start_attr_ok=, objc_foreach_object_declaration=, omp_declare_simd_clauses=, have_attrs=, attrs=, oacc_routine_data=, fallthru_attr_p=) at /repo/gcc-trunk/gcc/c/c-parser.cc:2544 #25 0x00d94a54 in c_parser_external_declaration (parser=0x776f7b40) at /repo/gcc-trunk/gcc/c/c-parser.cc:1779 #26 0x00d9549c in c_parser_translation_unit (parser=) at /repo/gcc-trunk/gcc/c/c-parser.cc:1652 #27 c_parse_file () at /repo/gcc-trunk/gcc/c/c-parser.cc:23357 #28 0x00df6c8e in c_common_parse_file () at /repo/gcc-trunk/gcc/c-family/c-opts.cc:1240 #29 0x013a3ede in compile_file () at /repo/gcc-trunk/gcc/toplev.cc:452 #30 0x00d0528e in do_compile (no_backend=false) at /repo/gcc-trunk/gcc/toplev.cc:2168 #31 toplev::main (this=this@entry=0x7fffd57e, argc=, argc@entry=17, argv=, argv@entry=0x7fffd6c8) at /repo/gcc-trunk/gcc/toplev.cc:2320 #32 0x00d071cf in main (argc=17, argv=0x7fffd6c8) at /repo/gcc-trunk/gcc/main.cc:39 The execution doesn't seem to ever finish. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-8242-20220425114659-gf0e170f72f8-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-8242-20220425114659-gf0e170f72f8-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220425 (experimental) (GCC)
[Bug c++/105373] miscompile involving lambda coroutines and an object bitwise copied instead of via the copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373 --- Comment #4 from Iain Sandoe --- I'm guessing that a reproducer is going to be hard to arrange (from the "complex piece of code") even though the failing point is well-defined?
[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287 --- Comment #6 from Iain Sandoe --- (In reply to David Malcolm from comment #5) > Thanks. FWIW I've filed PR 105382 to track the various other issues I'm > seeing with -fanalyzer with coroutines (though given that we don't properly > support C++ yet, that's relatively low priority for me). Yeah, even given bug-free coroutines (heh) I think we would need to teach the analyser about the outlining and deferred destruction etc.
[Bug target/105383] New: [11/12 Regression] ICE: in change_insns, at rtl-ssa/changes.cc:674 with -Os -fno-tree-dominator-opts -fno-tree-vrp -msseregparm -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105383 Bug ID: 105383 Summary: [11/12 Regression] ICE: in change_insns, at rtl-ssa/changes.cc:674 with -Os -fno-tree-dominator-opts -fno-tree-vrp -msseregparm -m32 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 52873 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52873=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -Os -fno-tree-dominator-opts -fno-tree-vrp -msseregparm -m32 testcase.c during RTL pass: fwprop1 testcase.c: In function 'foo': testcase.c:12:1: internal compiler error: in change_insns, at rtl-ssa/changes.cc:674 11 | } | ^ 0xce7bdd rtl_ssa::function_info::change_insns(array_slice) /repo/gcc-trunk/gcc/rtl-ssa/changes.cc:674 0x2458417 rtl_ssa::function_info::change_insn(rtl_ssa::insn_change&) /repo/gcc-trunk/gcc/rtl-ssa/changes.cc:717 0x2306d68 try_fwprop_subst_pattern /repo/gcc-trunk/gcc/fwprop.cc:553 0x2306d68 try_fwprop_subst /repo/gcc-trunk/gcc/fwprop.cc:627 0x230748c forward_propagate_and_simplify /repo/gcc-trunk/gcc/fwprop.cc:823 0x230748c forward_propagate_into /repo/gcc-trunk/gcc/fwprop.cc:886 0x230773b forward_propagate_into /repo/gcc-trunk/gcc/fwprop.cc:835 0x230773b fwprop_insn /repo/gcc-trunk/gcc/fwprop.cc:943 0x2307819 fwprop /repo/gcc-trunk/gcc/fwprop.cc:995 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-8242-20220425114659-gf0e170f72f8-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-8242-20220425114659-gf0e170f72f8-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220425 (experimental) (GCC)
[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287 --- Comment #5 from David Malcolm --- Thanks. FWIW I've filed PR 105382 to track the various other issues I'm seeing with -fanalyzer with coroutines (though given that we don't properly support C++ yet, that's relatively low priority for me).
[Bug analyzer/105382] New: Support for coroutines in -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105382 Bug ID: 105382 Summary: Support for coroutines in -fanalyzer Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Blocks: 97110 Target Milestone: --- -fanalyzer doesn't work well with C++ coroutines. For example, trying it on gcc/testsuite/g++.dg/coroutines/torture/co-yield-01-multi.C leads to: warning: dereference of possibly-NULL ‘’ [CWE-690] [-Wanalyzer-possible-null-dereference] 13 | f () noexcept | ^ ‘coro1 f()’: events 1-2 | | 13 | f () noexcept | | ~ | | | | | (2) ‘operator new(40)’ could be NULL: unchecked value from (1) |.. | 23 | } | | ^ | | | | | (1) this call could return NULL | along with numerous: warning: use of uninitialized value ‘’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value] e.g.: ../../src/gcc/testsuite/g++.dg/coroutines/torture/co-yield-01-multi.C:23:1: warning: use of uninitialized value ‘’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value] 23 | } | ^ ‘coro1 f()’: events 1-3 | | 13 | f () noexcept | | ^ | | || | | |(2) region created on stack here | | (1) entry to ‘f’ | | (3) calling ‘f’ from ‘f’ | +--> ‘void f(f()::_Z1fv.Frame*)’: events 4-10 | | 13 | f () noexcept | | ^ | | | | | (4) entry to ‘f’ | | (8) ...to here | | (9) following ‘true’ branch... | | (10) ...to here |.. | 23 | } | | ~ | | | | | (5) following ‘false’ branch... | | (6) ...to here | | (7) following ‘case 0:’ branch... | <--+ | ‘coro1 f()’: events 11-12 | | 13 | f () noexcept | | ^ | | | | | (11) returning to ‘f’ from ‘f’ |.. | 23 | } | | ~ | | | | | (12) use of uninitialized value ‘’ here | Note how the path refers to "case 0:"; I believe this is a reference to the synthetic switch for handling re-entering the coroutine: : _3 = frame_ptr_56(D)->_Coro_resume_index; _4 = (int) _3; switch (_4) [INV], case 1: [INV], case 3: [INV], case 5: [INV], case 7: [INV], case 9: [INV]> So I think that the way we generate events in diagnostic paths might need some kind of support for presenting the information in a form that more closely resembles what the user wrote, rather than the gimplification of what the C++ FE generated. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97110 [Bug 97110] [meta-bug] tracker bug for supporting C++ in -fanalyzer
[Bug fortran/105381] [12 Regression] Memory-hog since r12-8230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105381 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog Target Milestone|--- |12.0 CC||mikael at gcc dot gnu.org
[Bug fortran/105381] New: [12 Regression] Memory-hog since r12-8230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105381 Bug ID: 105381 Summary: [12 Regression] Memory-hog since r12-8230 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- The following reduced code shows an issue with an apparently infinite compile-time loop. MODULE m implicit none integer, parameter :: ncrit = 8 integer, parameter :: nterm = 7 contains subroutine new_thin_rule (rule1) character(*),intent(in) ,optional :: rule1(ncrit) character(len=8) :: rules (ncrit,nterm) rules = '' if (present (rule1)) rules(:,1) = rule1 ! <-- compile time hog end subroutine new_thin_rule end module m This eats lots of memory... Fails with r12-8230, works with r12-8223.
[Bug tree-optimization/104336] bogus -Wrestrict for std::string assignment with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104336
Mattias Ellert changed:
What|Removed |Added
CC||mattias.ellert at physics dot
uu.s
||e
--- Comment #1 from Mattias Ellert ---
Created attachment 52872
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52872=edit
Proposed fix
Proposed fix:
``` {.diff}
--- usr/include/c++/12/bits/basic_string.tcc.orig 2022-04-14
01:23:43.0 +0200
+++ usr/include/c++/12/bits/basic_string.tcc2022-04-25 16:18:57.028352162
+0200
@@ -527,10 +527,10 @@
}
else
{
- const size_type __nleft = (__p + __len1) - __s;
- this->_S_move(__p, __s, __nleft);
- this->_S_copy(__p + __nleft, __p + __len2,
- __len2 - __nleft);
+ const size_type __nleft = (__s + __len2) - (__p +
__len1);
+ this->_S_move(__p, __s, __len2 - __nleft);
+ this->_S_copy(__p + __len2 - __nleft, __p + __len2,
+ __nleft);
}
}
}
```
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 Segher Boessenkool changed: What|Removed |Added Attachment #52870|0 |1 is obsolete|| --- Comment #15 from Segher Boessenkool --- Created attachment 52871 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52871=edit proposed patch
[Bug fortran/105379] [12 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105379 Mikael Morin changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED CC||mikael at gcc dot gnu.org Last reconfirmed||2022-04-25 --- Comment #1 from Mikael Morin --- Caused by r12-8235-gfa5cd7102da676dcb1757b1288421f5f3439ae0e, I guess. So I am the culprit.
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 Segher Boessenkool changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #14 from Segher Boessenkool --- Created attachment 52870 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52870=edit proposed patch
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 --- Comment #13 from Segher Boessenkool --- Ah, it needs check_no_compiler_messages_nocache in these tests. Patch attached. Could you please test with it?
[Bug tree-optimization/105329] Bogus restrict warning when assigning 1-char string literal to std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 --- Comment #5 from Andrew Macleod --- Before inlining, the general code see: if (_27 <= __s_53(D)) goto ; [INV] else goto ; [INV] _34 = _27 - __s_53(D); __nleft_64 = (const size_type) _34 THe branch now registers the relation that __s_53 < _27, and this allows us to now determine that _34 and _nleft_64 is [1, 0x7FFF] THen we inline this code, and by the time we get to the restrict code, we have the following IL: [local count: 89889908]: if (_22 >= [(void *)"5" + 1B]) goto ; [50.00%] else goto ; [50.00%] <..> [local count: 44944954]: if (_22 <= "5") goto ; [50.00%] else goto ; [50.00%] <...> [local count: 22472477]: _48 = _22 - "5"; if (_48 == 1) goto ; [34.00%] else goto ; [66.00%] [local count: 7640642]: MEM[(char_type &)_22] = 53; pretmp_64 = MEM[(const struct basic_string *)s_2(D)]._M_dataplus._M_p; goto ; __nleft_49 = (const size_type) _48; __builtin_memcpy (_22, "5", __nleft_49); _28 = 1 - __nleft_49; _29 = _22 + 1; _140 = _22 + __nleft_49; __builtin_memcpy (_140, _29, _28); Our problem seems rooted in the calculation of _28. Ranger has figured out via feeding calculations based on the comparisons that nleft_49 cannot be 0 or 1 either, and therefore must be [2, 0x7FFF] But it means that _28 = 1 - __nleft_49; becomes a calculated range of [9223372036854775810, +INF] And that makes the warning code very unhappy when it is used as the number of bytes in the second memcpy. Previously, we hadn't made some of these conclusions, so we were looking at VARYING, so the warning code presumably ignored it. This code is actually dead, but its not being figured out. the pointer tracking does not recognize that if this branch is NOT taken: if (_22 >= [(void *)"5" + 1B]) then we follow the following sequence: [local count: 44944954]: if (_22 <= "5") goto ; [50.00%] else goto ; [50.00%] [local count: 22472477]: _42 = "5" - _22; _43 = (long unsigned int) _42; __poff_45 = _43 + 1; _46 = _22 + __poff_45; _47 = MEM[(const char_type &)_46]; MEM[(char_type &)_22] = _47; pretmp_83 = MEM[(const struct basic_string *)s_2(D)]._M_dataplus._M_p; goto ; [100.00%] [local count: 22472477]: _48 = _22 - "5"; if (_48 == 1) I believe the very first if can never take the edge 11->13... and thus the rest of that code should go. for the general case, The tracking of _22 needs to recognize that when we get to bb12 that the expression "5" - 22 and in bb13 _22 - "5" have very strict ranges. in fact, they are [0,0] in think case I think. That is certainly beyond rangers current capabilities. I thought that the reference tracking used by the warning system tried to do that. Regardless, when we introduce prange (pointer ranges) next cycle perhaps there is something we can do to track the base an offsets based on the conditions.
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 --- Comment #12 from Jakub Jelinek --- I said that above, -mdejagnu-cpu=power10 isn't passed to the effective target snippet compilation, so it doesn't test whether the test with -mdejagnu-cpu=power10 will be power10, but rather tests whether the compiler is configured to default to -mcpu=power10 or perhaps whether this is --target_board=unix/-mcpu=power10 testing: Executing on host: /usr/src/gcc/objp16/gcc/xgcc -B/usr/src/gcc/objp16/gcc/ -m32 -fdiagnostics-plain-output -mcpu=power10 -c -o power10_ok1793558.o power10_ok1793558.c(timeout = 300) spawn -ignore SIGHUP /usr/src/gcc/objp16/gcc/xgcc -B/usr/src/gcc/objp16/gcc/ -m32 -fdiagnostics-plain-output -mcpu=power10 -c -o power10_ok1793558.o power10_ok1793558.c Executing on host: /usr/src/gcc/objp16/gcc/xgcc -B/usr/src/gcc/objp16/gcc/ /usr/src/gcc/gcc/testsuite/gcc.target/powerpc/bswap-brw.c -m32 -fdiagnostics-plain-output -O2 -mdejagnu -cpu=power10 -ffat-lto-objects -fno-ident -S -o bswap-brw.s(timeout = 300) spawn -ignore SIGHUP /usr/src/gcc/objp16/gcc/xgcc -B/usr/src/gcc/objp16/gcc/ /usr/src/gcc/gcc/testsuite/gcc.target/powerpc/bswap-brw.c -m32 -fdiagnostics-plain-output -O2 -mdejagnu-c pu=power10 -ffat-lto-objects -fno-ident -S -o bswap-brw.s Executing on host: /usr/src/gcc/objp16/gcc/xgcc -B/usr/src/gcc/objp16/gcc/ exceptions_enabled1793558.cc -m32 -fdiagnostics-plain-output -S -o exceptions_enabled1793558.s(time out = 300) spawn -ignore SIGHUP /usr/src/gcc/objp16/gcc/xgcc -B/usr/src/gcc/objp16/gcc/ exceptions_enabled1793558.cc -m32 -fdiagnostics-plain-output -S -o exceptions_enabled1793558.s PASS: gcc.target/powerpc/bswap-brw.c (test for excess errors) PASS: gcc.target/powerpc/bswap-brw.c scan-assembler \\mbrw\\M Executing on host: /usr/src/gcc/objp16/gcc/xgcc -B/usr/src/gcc/objp16/gcc/ arch_pwr101793558.c -m32 -fdiagnostics-plain-output -S -o arch_pwr101793558.s(timeout = 300) spawn -ignore SIGHUP /usr/src/gcc/objp16/gcc/xgcc -B/usr/src/gcc/objp16/gcc/ arch_pwr101793558.c -m32 -fdiagnostics-plain-output -S -o arch_pwr101793558.s arch_pwr101793558.c:3:18: error: #error does not have power10 support. compiler exited with status 1 FAIL: gcc.target/powerpc/bswap-brw.c scan-assembler \\mxxbrw\\M
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 --- Comment #11 from seurer at gcc dot gnu.org --- It is still failing with latest trunk: spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/bswap-brw.c -m32 -fdiagnostics-plain-output -O2 -mdejagnu-cpu=power10 -ffat-lto-objects -fno-ident -S -o bswap-brw.s^M FAIL: gcc.target/powerpc/bswap-brw.c scan-assembler \\mxxbrw\\M g:235f88dbc3494c49e0f361a5a3f78491f72ff47c, r12-8247-g235f88dbc3494c seurer@makalu-lp1:~/gcc/git/build/gcc-test$ diff -c bswap-brw.s.r12-8220 bswap-brw.s.r12-8221 *** bswap-brw.s.r12-8220Mon Apr 25 12:22:57 2022 --- bswap-brw.s.r12-8221Mon Apr 25 12:29:35 2022 *** *** 28,37 # 0 # 0 "" 2 #NO_APP ! xxbrw 0,0 addi 9,1,8 ! xxextractuw 1,0,4 ! stfiwx 0,0,9 addi 1,1,16 .cfi_def_cfa_offset 0 fcfid 1,1 --- 28,38 # 0 # 0 "" 2 #NO_APP ! mfvsrwz 9,0 ! brw 9,9 ! stw 9,8(1) addi 9,1,8 ! lfiwzx 1,0,9 addi 1,1,16 .cfi_def_cfa_offset 0 fcfid 1,1
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 --- Comment #10 from Segher Boessenkool --- The feature test output you show was run without the dg-options... Something is seriously wrong if that is the one that was used!
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 --- Comment #9 from Segher Boessenkool --- Ah, lol. Yes. But please don't change this yet, it should work thew way it is now, this should be fixed. Do you see what makes the _ARCH_PWR10 test fail on your system?
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 --- Comment #8 from Jakub Jelinek --- As it uses -mdejagnu-cpu=power10, it only tests power10 code generation, nothing else.
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 --- Comment #7 from Segher Boessenkool --- The test generates the expected code for all other cpus.
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #6 from Jakub Jelinek ---
Somehow that doesn't really work, in the log I see that has_arch_pwr10 is
tested but yields it is not on:
/usr/src/gcc/objp16/gcc/xgcc -B/usr/src/gcc/objp16/gcc/ arch_pwr101791933.c
-m32 -fdiagnostics-plain-output -S -o arch_pwr101791933.s(timeout = 300)
spawn -ignore SIGHUP /usr/src/gcc/objp16/gcc/xgcc -B/usr/src/gcc/objp16/gcc/
arch_pwr101791933.c -m32 -fdiagnostics-plain-output -S -o arch_pwr101791933.s
arch_pwr101791933.c:3:18: error: #error does not have power10 support.
compiler exited with status 1
- the -mdejagnu-cpu=power10 option from the command line isn't clearly passed
to the effective target test compilation.
If I do:
--- gcc/testsuite/gcc.target/powerpc/bswap-brw.c.jj 2022-04-22
13:36:56.136961022 +0200
+++ gcc/testsuite/gcc.target/powerpc/bswap-brw.c2022-04-25
19:16:46.528029452 +0200
@@ -17,6 +17,6 @@ bswap_int_dbl (unsigned int a)
/* Force the value to be loaded into a vector register. */
__asm__ (" # %x0" : "+wa" (b));
- /* { dg-final { scan-assembler {\mxxbrw\M} {xfail {has_arch_pwr10 && {!
has_arch_ppc64}}} } } */
+ /* { dg-final { scan-assembler {\mxxbrw\M} {xfail { ! { has_arch_ppc64 } } }
} } */
return (double) __builtin_bswap32 (b);
}
then the test passes both
make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
powerpc.exp=bswap-brw.c'
(in x86_64-linux -> powerpc64-linux cross).
What is the point of has_arch_pwr10 test in there? When -mdejagnu-cpu=power10
is used, then it is power10 when it is being compiled always, no?
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349
--- Comment #5 from Segher Boessenkool ---
And that is what the {xfail {has_arch_pwr10 && {! has_arch_ppc64}}}
is for. Does that not work for you? Why doesn't it, it works fine here?
It would be nice if this unimportant edge case was costed better as well of
course, but it wasn't worth blocking this important regression fix on it.
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374 --- Comment #7 from Martin Liška --- (In reply to Martin Liška from comment #6) > Btw. started with r12-7338-g884f77b489 if that helps. Oh, it was already discovered by Jakub.
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-04-25 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org --- Comment #6 from Martin Liška --- Btw. started with r12-7338-g884f77b489 if that helps.
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 --- Comment #4 from Jakub Jelinek --- With a x86_64-linux -> powerpc64-linux cross, I can see with -mcpu=power10 -m32 --- bswap-brw.s12022-04-25 18:32:35.108799457 +0200 +++ bswap-brw.s22022-04-25 18:32:38.664750135 +0200 @@ -28,10 +28,11 @@ bswap_int_dbl: # 0 # 0 "" 2 #NO_APP - xxbrw 0,0 + mfvsrwz 9,0 + brw 9,9 + stw 9,8(1) addi 9,1,8 - xxextractuw 1,0,4 - stfiwx 0,0,9 + lfiwzx 1,0,9 addi 1,1,16 .cfi_def_cfa_offset 0 fcfid 1,1 @@ -39,6 +40,6 @@ bswap_int_dbl: .cfi_endproc .LFE1: .size bswap_int_dbl,.-bswap_int_dbl - .ident "GCC: (GNU) 12.0.1 20220310 (experimental)" + .ident "GCC: (GNU) 12.0.1 20220425 (experimental)" .gnu_attribute 4, 1 .section.note.GNU-stack,"",@progbits difference, with -m64 xxbrw is still there even with latest trunk.
[Bug libstdc++/105375] std::packaged_task has no deduction guide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |11.4 --- Comment #8 from Jonathan Wakely --- Fixed for GCC 12, but worth backporting to GCC 11 too.
[Bug fortran/105380] ICE in gfc_conv_array_initializer, at fortran/trans-array.cc:6317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105380 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- On the other hand, test versions are affected down to r8 : (gcc configured with --enable-checking=yes) $ gfortran-12-20220424 -c z1.f90 z1.f90:10:3: 10 | end | 1 internal compiler error: tree check: expected array_type, have record_type in gfc_conv_array_initializer, at fortran/trans-array.cc:6317 0x6addd6 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/tree.cc:8798 0x7fc3f2 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/tree.h:3457 0x7fc3f2 gfc_conv_array_initializer(tree_node*, gfc_expr*) ../../gcc/fortran/trans-array.cc:6317 0x842b00 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.cc:8393 0x842f20 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc/fortran/trans-expr.cc:9308 0x842c59 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.cc:8428 0x814170 gfc_emit_parameter_debug_info ../../gcc/fortran/trans-decl.cc:5513 0x7d0742 do_traverse_symtree ../../gcc/fortran/symbol.cc:4174 0x826bc3 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7818 0x7984ce translate_all_program_units ../../gcc/fortran/parse.cc:6669 0x7984ce gfc_parse_file() ../../gcc/fortran/parse.cc:6956 0x7e653f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug fortran/105380] New: ICE in gfc_conv_array_initializer, at fortran/trans-array.cc:6317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105380 Bug ID: 105380 Summary: ICE in gfc_conv_array_initializer, at fortran/trans-array.cc:6317 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Something has changed between 20220306 and 20220327, relevant especially for release versions : $ cat z1.f90 program p type t(n) integer, len :: n end type type t2(m) integer, len :: m type(t(1)) :: a(m) end type type(t2(3)) :: x end $ gfortran-12-20220306 -c z1.f90 $ $ gfortran-12-20220424 -c z1.f90 z1.f90:10:3: 10 | end | 1 internal compiler error: Segmentation fault 0xccf18f crash_signal ../../gcc/toplev.cc:322 0x7c2197 wi::extended_tree<576>::get_len() const ../../gcc/tree.h:6179 0x7c2197 wi::int_traits > >::decompose(long*, unsigned int, generic_wide_int > const&) ../../gcc/wide-int.h:985 0x7c2197 wide_int_ref_storage::wide_int_ref_storage > >(generic_wide_int > const&, unsigned int) ../../gcc/wide-int.h:1034 0x7c2197 generic_wide_int >::generic_wide_int > >(generic_wide_int > const&, unsigned int) ../../gcc/wide-int.h:790 0x7c2197 bool wi::lts_p >, generic_wide_int > >(generic_wide_int > const&, generic_wide_int > const&) ../../gcc/wide-int.h:1904 0x7c2197 wi::binary_traits >, generic_wide_int >, wi::int_traits > >::precision_type, wi::int_traits > >::precision_type>::signed_predicate_result operator< >, generic_wide_int > >(generic_wide_int > const&, generic_wide_int > const&) ../../gcc/wide-int.h:3250 0x7c2197 tree_int_cst_lt(tree_node const*, tree_node const*) ../../gcc/tree.h:6335 0x7c2197 gfc_conv_array_initializer(tree_node*, gfc_expr*) ../../gcc/fortran/trans-array.cc:6316 0x7efa40 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.cc:8393 0x7dc1e3 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc/fortran/trans-expr.cc:9308 0x7efb99 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc/fortran/trans-expr.cc:8428 0x7c6ba5 gfc_emit_parameter_debug_info ../../gcc/fortran/trans-decl.cc:5513 0x78f282 do_traverse_symtree ../../gcc/fortran/symbol.cc:4174 0x7d4d18 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7818 0x75700e translate_all_program_units ../../gcc/fortran/parse.cc:6669 0x75700e gfc_parse_file() ../../gcc/fortran/parse.cc:6956 0x7a44af gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug fortran/105379] New: [12 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105379 Bug ID: 105379 Summary: [12 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20220417 and 20220424 : $ cat z1.f90 program p type t end type contains subroutine s1(x) class(t) :: x(3) end subroutine s2(n, x) integer :: n class(t) :: x(n) end end $ cat z2.f90 program p type t end type integer :: m = 3 contains subroutine s1(x) class(t) :: x(3) end subroutine s3(x) class(t) :: x(m) end end $ gfortran-12-20220424 -c z1.f90 f951: internal compiler error: gfc_compare_array_spec(): Array spec clobbered 0x6f15b9 gfc_report_diagnostic ../../gcc/fortran/error.cc:883 0x6f3137 gfc_internal_error(char const*, ...) ../../gcc/fortran/error.cc:1503 0x6be47f compare_bounds ../../gcc/fortran/array.cc:971 0x6bfde3 gfc_compare_array_spec(gfc_array_spec*, gfc_array_spec*) ../../gcc/fortran/array.cc:1012 0x6ff3dc compare_components ../../gcc/fortran/interface.cc:495 0x6ff6d0 gfc_compare_derived_types(gfc_symbol*, gfc_symbol*) ../../gcc/fortran/interface.cc:678 0x834de8 gfc_copy_dt_decls_ifequal(gfc_symbol*, gfc_symbol*, bool) ../../gcc/fortran/trans-types.cc:2453 0x8342c4 gfc_get_derived_type(gfc_symbol*, int) ../../gcc/fortran/trans-types.cc:2922 0x834d18 gfc_typenode_for_spec(gfc_typespec*, int) ../../gcc/fortran/trans-types.cc:1195 0x834f78 gfc_sym_type(gfc_symbol*, bool) ../../gcc/fortran/trans-types.cc:2307 0x83344f gfc_get_function_type(gfc_symbol*, gfc_actual_arglist*, char const*) ../../gcc/fortran/trans-types.cc:3161 0x7c7424 build_function_decl ../../gcc/fortran/trans-decl.cc:2393 0x7cf3a6 gfc_create_function_decl(gfc_namespace*, bool) ../../gcc/fortran/trans-decl.cc:3102 0x7d48be gfc_generate_contained_functions ../../gcc/fortran/trans-decl.cc:5768 0x7d48be gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7586 0x75700e translate_all_program_units ../../gcc/fortran/parse.cc:6669 0x75700e gfc_parse_file() ../../gcc/fortran/parse.cc:6956 0x7a44af gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:216
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- https://gcc.gnu.org/pipermail/gcc-testresults/2022-April/760251.html certainly shows the FAIL: gcc.target/powerpc/bswap-brw.c scan-assembler \\mxxbrw\\M even when it is r12-8242 . --with-cpu=power8 powerpc64-linux-gnu
[Bug libstdc++/105375] std::packaged_task has no deduction guide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a5cee0480c10bafa8ed65d49e5cedca23d98d7b7 commit r12-8249-ga5cee0480c10bafa8ed65d49e5cedca23d98d7b7 Author: Jonathan Wakely Date: Mon Apr 25 14:22:41 2022 +0100 libstdc++: Add deduction guides for std::packaged_task [PR105375] This change was LWG 3117. The test is copied from 20_util/function/cons/deduction.cc libstdc++-v3/ChangeLog: PR libstdc++/105375 * include/std/future (packaged_task): Add deduction guides. * testsuite/30_threads/packaged_task/cons/deduction.cc: New test.
[Bug analyzer/105366] [11/12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer since r11-4511-gf635f0ce87d687b1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105366 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from David Malcolm --- Thanks for filing this bug; I'm testing a fix. Seems to be the same root cause as PR105365; I'm not sure why one manifests with GCC 11 and the other doesn't.
[Bug analyzer/105365] [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -fanalyzer since r12-2337-g33255ad3ac14e395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105365 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from David Malcolm --- Thanks for filing this bug; I'm testing a fix.
[Bug rtl-optimization/105314] [12 Regression] ifcvt regression in noce_try_store_flag_mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105314 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 52869 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52869=edit gcc12-pr105314.patch Untested fix.
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374 --- Comment #5 from Christophe Lyon --- > Regarding the dg-* directives, I suspect you need arm_v8_1m_mve_fp_ok since > the test involves floats. I was wrong and your proposal of arm_v8_1m_mve_ok looks fine (since actually there is no ICE with compiling for an FP-capable FPU)
[Bug c++/105353] __builtin_shufflevector with value dependent constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105353 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Marek Polacek --- Fixed.
[Bug c++/105353] __builtin_shufflevector with value dependent constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105353 --- Comment #7 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:1ba397e9f93d3abc93a6ecbabc3d873489a6fb7f commit r12-8248-g1ba397e9f93d3abc93a6ecbabc3d873489a6fb7f Author: Marek Polacek Date: Fri Apr 22 19:40:27 2022 -0400 c++: __builtin_shufflevector with value-dep expr [PR105353] Here we issue an error from c_build_shufflevector while parsing a template because it got a TEMPLATE_PARM_INDEX, but this function expects INTEGER_CSTs (except the first two arguments). It checks if any of the arguments are type-dependent, if so, we leave the processing for later, but it should also check value-dependency for the 3rd+ arguments, so as to avoid the problem above. This is not a regression -- __builtin_shufflevector was introduced in GCC 12, but it looks safe enough. PR c++/105353 gcc/cp/ChangeLog: * typeck.cc (build_x_shufflevector): Use instantiation_dependent_expression_p except for the first two arguments. gcc/testsuite/ChangeLog: * g++.dg/ext/builtin-shufflevector-3.C: New test.
[Bug middle-end/105348] Overly aggressive -Warray-bounds after conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105348 --- Comment #3 from Thiago Macieira --- I understand. I'm just trying to avoid having to add code for a corner-case. People don't usually parse empty buffers, so it's usually fine to allow it to proceed and discover an EOF condition. Anyway, worked around. Feel free to close if this is too hard to fix.
[Bug libstdc++/105375] std::packaged_task has no deduction guide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375 --- Comment #6 from Jonathan Wakely --- (In reply to raldone01 from comment #5) > Thank you for your reply. > What does that mean? As it says at the link in comment 4, "The following behavior-changing defect reports were applied retroactively to previously published C++ standards." > Are defect reports updates for older standards? Yes. > Is it meant to be available at some point in c++17? Yes.
[Bug target/105338] [12 Regression] Regression: jump or cmove generated for pattern (x ? CST : 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105338
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #12 from Jakub Jelinek ---
Fixed. I think you can use if (__builtin_expect_with_probability (!b, 0, 0.5))
return -2; else return 0; if you want to override the return negative
heuristics.
Or if you use it in places where that heuristics doesn't trigger, say:
int bar (int);
int g(int i) {
return bar (i ? -2 : 0);
}
[Bug c++/105377] Likely a misleading clang warning -Wc++20-attribute-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377 --- Comment #4 from Jonathan Wakely --- But we don['t want to use gnu++17 because we want the compiler to be built using portable ISO C++17. An unrecognized attribute is a portable ISO C++17 construct, it just doesn't do anything (except maybe give a warning). We could add: #ifdef __clang__ #pragma clang diagnostic ignored "-Wc++20-attribute-extensions" #endif To disable this warning, since we know we're already guarding the attribute with __has_cpp_attribute.
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374 --- Comment #4 from Christophe Lyon --- Other MVE tests are in gcc.target/arm/simd/ (eg mve-vcmp-f32.c), maybe it's best to keep them in the same place? Regarding the dg-* directives, I suspect you need arm_v8_1m_mve_fp_ok since the test involves floats. Thanks for the prompt fix!
[Bug tree-optimization/105276] [12 Regression] executed once loop not optimized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105276 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Andrew Macleod --- fixed.
[Bug c/105378] New: [OpenMP][5.1] 'nowait' on 'taskwait' not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105378 Bug ID: 105378 Summary: [OpenMP][5.1] 'nowait' on 'taskwait' not supported Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Just to make sure it does not get forgotten as appendix B does not make it clear. Testcase: https://github.com/SOLLVE/sollve_vv/pull/474 Currently fails with: test_task_nowait.c:32:30: error: ‘nowait’ is not valid for ‘#pragma omp taskwait’ 32 | #pragma omp taskwait nowait | ^~ and applies to all FE.
[Bug c++/105377] Likely a misleading clang warning -Wc++20-attribute-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- it's probably due to the combination of -pedantic and -std=c++17; what happens if you use -std=gnu++17 instead for the standard?
[Bug tree-optimization/105276] [12 Regression] executed once loop not optimized anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105276 --- Comment #4 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:362e2a9c6297203bcf7f66bfb51dffb82b42d3b3 commit r12-8246-g362e2a9c6297203bcf7f66bfb51dffb82b42d3b3 Author: Andrew MacLeod Date: Mon Apr 25 09:56:35 2022 -0400 Retain existing range knowledge when prefilling statements. When range_of_stmt was adjusted to avoid large recursion depth, we need to intersect the calculated range whth the any known range to avoid losing info. Range_of_stmt does this, but the new prefill code missed it. PR tree-optimization/105276 gcc/ * gimple-range.cc (gimple_ranger::prefill_stmt_dependencies): Include existing global range with calculated value. gcc/testsuite/ * g++.dg/pr105276.C: New.
[Bug c++/105377] Likely a misleading clang warning -Wc++20-attribute-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377 --- Comment #2 from Marek Polacek --- Yes, I'd prefer to keep it the way it is.
[Bug c++/105377] Likely a misleading clang warning -Wc++20-attribute-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Yes, it is an extension, but if the compiler doesn't recognize it, it shouldn't do anything with it. So it is just fine to use it... Especially when gcc only uses it when the compiler tells it it supports it... #ifdef __has_cpp_attribute # if __has_cpp_attribute(likely) # define ATTR_LIKELY [[likely]] # elif __has_cpp_attribute(__likely__) # define ATTR_LIKELY [[__likely__]] # else # define ATTR_LIKELY # endif #else # define ATTR_LIKELY #endif
[Bug libstdc++/105375] std::packaged_task has no deduction guide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375 --- Comment #5 from raldone01 --- Thank you for your reply. What does that mean? Are defect reports updates for older standards? Is it meant to be available at some point in c++17?
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374
--- Comment #3 from Jakub Jelinek ---
Also, no idea where exactly to put the testcase to and what dg-* directives to
use, arm testcases is something I'm really not familiar with.
Perhaps gcc.target/arm/mve/general
and
/* { dg-do compile } */
/* { dg-require-effective-target arm_v8_1m_mve_ok } */
/* { dg-add-options arm_v8_1m_mve } */
but can -mfloat-abi=hard be just added or does it require some extra magic?
[Bug c++/105377] New: Likely a misleading clang warning -Wc++20-attribute-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105377 Bug ID: 105377 Summary: Likely a misleading clang warning -Wc++20-attribute-extensions 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, redi at gcc dot gnu.org Target Milestone: --- I noticed the following warning: clang++ -I/home/marxin/Programming/gcc/libcpp -I. -I/home/marxin/Programming/gcc/libcpp/../include -I/home/marxin/Programming/gcc/libcpp/include -g -O2 -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -fno-exceptions -fno-rtti -I/home/marxin/Programming/gcc/libcpp -I. -I/home/marxin/Programming/gcc/libcpp/../include -I/home/marxin/Programming/gcc/libcpp/include -fPIC -fcf-protection -c -o lex.o -MT lex.o -MMD -MP -MF .deps/lex.Tpo /home/marxin/Programming/gcc/libcpp/lex.cc -std=c++17 /home/marxin/Programming/gcc/libcpp/lex.cc:1289:7: warning: use of the 'likely' attribute is a C++20 extension [-Wc++20-attribute-extensions] ATTR_LIKELY case kind::NONE: ^~~ /home/marxin/Programming/gcc/libcpp/system.h:427:25: note: expanded from macro 'ATTR_LIKELY' # define ATTR_LIKELY [[likely]] ~~^~~~
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |12.0 Priority|P3 |P1
[Bug tree-optimization/105374] [12 Regression] ICE in fold_convert_loc, at fold-const.cc:2580 during GIMPLE pass: reassoc since r12-7338-g884f77b4222289510e1df9db2889b60c5df6fcda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105374
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
This can (and IMHO should no matter what) be fixed in reassoc by:
--- gcc/tree-ssa-reassoc.cc.jj 2022-04-14 13:46:59.690140053 +0200
+++ gcc/tree-ssa-reassoc.cc 2022-04-25 15:34:03.811473537 +0200
@@ -2254,7 +2254,11 @@ eliminate_redundant_comparison (enum tre
BIT_AND_EXPR or BIT_IOR_EXPR was of a wider integer type,
we need to convert. */
if (!useless_type_conversion_p (TREE_TYPE (curr->op), TREE_TYPE (t)))
- t = fold_convert (TREE_TYPE (curr->op), t);
+ {
+ if (!fold_convertible_p (TREE_TYPE (curr->op), t))
+ continue;
+ t = fold_convert (TREE_TYPE (curr->op), t);
+ }
if (TREE_CODE (t) != INTEGER_CST
&& !operand_equal_p (t, curr->op, 0))
But another question is if we shouldn't actually optimize it rather than
punting out.
The reason why that happens is that while eliminate_redundant_comparison
indirectly passes the V4BImode vector type as TYPE argument, the function
doesn't actually use it and uses truth_type (V4SImode) instead.
truth_type use has been introduced in r0-119133-gae22ac3c62db451bae
but at that point the type argument didn't exist.
That has been only introduced in r10-3154-g5f487a349de62613d7fa429 .
I wonder if we can't just kill the truth_type computation and replace all uses
with type...
[Bug rtl-optimization/105376] ICE: in decimal_to_decnumber, at dfp.cc:134 with _Decimal128 at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105376 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-04-25 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- It's there at least since GCC 4.8.
[Bug libstdc++/105375] std::packaged_task has no deduction guide.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105375 --- Comment #4 from Jonathan Wakely --- Ah it's noted as a DR at https://en.cppreference.com/w/cpp/thread/packaged_task#Defect_reports
[Bug rtl-optimization/105376] New: ICE: in decimal_to_decnumber, at dfp.cc:134 with _Decimal128 at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105376 Bug ID: 105376 Summary: ICE: in decimal_to_decnumber, at dfp.cc:134 with _Decimal128 at -O -g Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 52868 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52868=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O -g testcase.c during RTL pass: final testcase.c: In function 'foo': testcase.c:6:1: internal compiler error: in decimal_to_decnumber, at dfp.cc:134 6 | } | ^ 0x22f0853 decimal_to_decnumber /repo/gcc-trunk/gcc/dfp.cc:134 0x22f0adf encode_decimal128(real_format const*, long*, real_value const*) /repo/gcc-trunk/gcc/dfp.cc:269 0x12e6585 real_to_target(long*, real_value const*, format_helper) /repo/gcc-trunk/gcc/real.cc:2838 0xf1d9b3 insert_float /repo/gcc-trunk/gcc/dwarf2out.cc:20173 0xf560d6 mem_loc_descriptor(rtx_def*, machine_mode, machine_mode, var_init_status) /repo/gcc-trunk/gcc/dwarf2out.cc:16654 0xf5642e mem_loc_descriptor(rtx_def*, machine_mode, machine_mode, var_init_status) /repo/gcc-trunk/gcc/dwarf2out.cc:16481 0xf563c9 mem_loc_descriptor(rtx_def*, machine_mode, machine_mode, var_init_status) /repo/gcc-trunk/gcc/dwarf2out.cc:16470 0xf5b30a loc_descriptor /repo/gcc-trunk/gcc/dwarf2out.cc:17357 0xf5b70a dw_loc_list_1 /repo/gcc-trunk/gcc/dwarf2out.cc:17460 0xf5bc59 dw_loc_list /repo/gcc-trunk/gcc/dwarf2out.cc:17743 0xf51819 loc_list_from_tree_1 /repo/gcc-trunk/gcc/dwarf2out.cc:18939 0xf6198d loc_list_from_tree /repo/gcc-trunk/gcc/dwarf2out.cc:19642 0xf6198d add_location_or_const_value_attribute /repo/gcc-trunk/gcc/dwarf2out.cc:20861 0xf61ca7 gen_formal_parameter_die /repo/gcc-trunk/gcc/dwarf2out.cc:22966 0xf44425 gen_subprogram_die /repo/gcc-trunk/gcc/dwarf2out.cc:23978 0xf4911c gen_decl_die /repo/gcc-trunk/gcc/dwarf2out.cc:26977 0xf4a12b dwarf2out_decl /repo/gcc-trunk/gcc/dwarf2out.cc:27555 0xf4a5de dwarf2out_function_decl /repo/gcc-trunk/gcc/dwarf2out.cc:27570 0xfd16e2 rest_of_handle_final /repo/gcc-trunk/gcc/final.cc:4321 0xfd16e2 execute /repo/gcc-trunk/gcc/final.cc:4363 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-8242-20220425114659-gf0e170f72f8-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-8242-20220425114659-gf0e170f72f8-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220425 (experimental) (GCC)
[Bug analyzer/105366] [11/12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -O -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105366 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-04-25 --- Comment #1 from Martin Liška --- Started with r11-4511-gf635f0ce87d687b1.
[Bug analyzer/105365] [12 Regression] ICE: in cmp_cst, at analyzer/svalue.cc:309 with -fanalyzer since r12-2337-g33255ad3ac14e395
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105365 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-04-25 Ever confirmed|0 |1 Summary|[12 Regression] ICE: in |[12 Regression] ICE: in |cmp_cst, at |cmp_cst, at |analyzer/svalue.cc:309 with |analyzer/svalue.cc:309 with |-fanalyzer |-fanalyzer since ||r12-2337-g33255ad3ac14e395 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r12-2337-g33255ad3ac14e395.
[Bug tree-optimization/102879] [12 Regression] Dead Code Elimination Regression at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102879 Richard Biener changed: What|Removed |Added Priority|P1 |P3 --- Comment #5 from Richard Biener --- There's nothing special about this bug that makes it more important that the other "DCE" regressions identified against GCC 12 like PRs 102540, 102705, 102892, 102981, 102982, 103388, 104530, 105086.
