[Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103627 --- Comment #7 from Arseny Solokha --- Should this PR be closed, or are there backports pending?
[Bug debug/104544] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104544 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-02-15 CC||pinskia at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |10.4 --- Comment #1 from Andrew Pinski --- The difference starts in combine.
[Bug tree-optimization/104543] [12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104543 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-02-15 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed. >From what I could tell it is the unroll and jam pass which is messing up. -fno-loop-unroll-and-jam [local count: 542102826]: # c.4_21 = PHI <0(7), _9(23)> _7 = a[c.4_21]; _8 = _7 ^ 1; a[c.4_21] = _8; _9 = c.4_21 + 1; _11 = b_lsm.13_13 + 1; if (_11 <= 2) goto ; [83.33%] else goto ; [16.67%] [local count: 451752355]: a[c.4_21] = _7;
[Bug debug/104544] New: [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104544
Bug ID: 104544
Summary: [10/11/12 Regression] '-fcompare-debug' failure
(length) w/ -O2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: compare-debug-failure
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
Created attachment 52444
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52444&action=edit
gkd diff
gcc 12.0.1 20220213 snapshot (g:58aeb75d4097010ad9bb72b964265b18ab284f93) fails
-fcompare-debug check when compiling the following testcase w/ -O2:
int m, n;
__int128 q;
void
bar (unsigned __int128 x, int y)
{
if (x)
q += y;
}
void
foo (void)
{
bar (!!q - 1, (m += m ? m : 1) < n);
}
% aarch64-linux-gnu-gcc-12.0.1 -O2 -fcompare-debug -c tod26vmj.c
aarch64-linux-gnu-gcc-12.0.1: error: tod26vmj.c: '-fcompare-debug' failure
(length)
gkd diff attached.
[Bug tree-optimization/104543] [12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104543 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||wrong-code Summary|wrong code at -O3 on|[12 Regression] wrong code |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu
[Bug tree-optimization/104543] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104543 --- Comment #1 from Zhendong Su --- >From Compiler Explorer: https://godbolt.org/z/s1WW4snzM
[Bug tree-optimization/104543] New: wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104543
Bug ID: 104543
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This appears to be a recent regression.
[588] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220215 (experimental) [master r12-7236-g2c3309e3d0f] (GCC)
[589] %
[589] % gcctk -O2 small.c; ./a.out
[590] %
[590] % gcctk -O3 small.c
[591] % ./a.out
Aborted
[592] %
[592] % cat small.c
int a[3], b, c;
int e() {
if (!c) {
for (b = 0; b < 3; b++)
for (c = 0; c < 3; c++)
a[c] ^= 1;
return -1;
}
return 0;
}
int main() {
e();
if (a[1] != 1)
__builtin_abort();
return 0;
}
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 96864, which changed state. Bug 96864 Summary: loop not vectorized due AVX512 condition handling https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96864 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/96864] loop not vectorized due AVX512 condition handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96864 Hongtao.liu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Hongtao.liu --- .
[Bug target/96864] loop not vectorized due AVX512 condition handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96864 --- Comment #2 from Hongtao.liu --- Fixed in GCC12 by r12-6756-g8bc700f4c3fbe405413db02281ef2918bfa831fc.
[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464 Hongtao.liu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Hongtao.liu --- Fixed in GCC12.
[Bug rtl-optimization/104059] [12 Regression] cprop_hardreg propgates hard registers for mov instructions between different REG_CLASS without considering cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104059 Hongtao.liu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Hongtao.liu --- Fixed in GCC12.
[Bug libstdc++/104542] New: make_obj_using_allocator and uninitialized_construct_using_allocator lack constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104542 Bug ID: 104542 Summary: make_obj_using_allocator and uninitialized_construct_using_allocator lack constexpr Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: de34 at live dot cn Target Milestone: --- std::make_obj_using_allocator and std::uninitialized_construct_using_allocator are constexpr in C++20 (LWG3185, LWG3321), but currently they are not constexpr in libstdc++. I think the related compiler support for std::construct_at is available since gcc11 (partially available in gcc10), so these functions are reasonably constexpr in libstdc++ now, and this fix should be backported to gcc 10/11. wandbox links: gcc10 with manual constexpr (lacks support for CZ044): https://wandbox.org/permlink/CvSEindXZa3MMRT5 gcc11&12 with manual constexpr: https://wandbox.org/permlink/8i7oM16jGxlmz3FC https://wandbox.org/permlink/VHQJhGINcdpNC0Eh gcc11&12 with std versions, currently doesn't compile: https://wandbox.org/permlink/ZUx1xZIOphwxcJhS https://wandbox.org/permlink/f8uujdEoMUPbsUIq
[Bug rtl-optimization/104541] New: [10/11/12 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -O -fno-tree-ter -fsanitize-coverage=trace-cmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104541 Bug ID: 104541 Summary: [10/11/12 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -O -fno-tree-ter -fsanitize-coverage=trace-cmp 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 Target: x86_64-pc-linux-gnu Created attachment 52443 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52443&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O -fno-tree-ter -fsanitize-coverage=trace-cmp testcase.c during RTL pass: reload testcase.c: In function 'foo': testcase.c:9:1: internal compiler error: maximum number of LRA assignment passes is achieved (30) 9 | } | ^ 0x11b641c lra_assign(bool&) /repo/gcc-trunk/gcc/lra-assigns.cc:1694 0x11b07ef lra(_IO_FILE*) /repo/gcc-trunk/gcc/lra.cc:2395 0x1161129 do_reload /repo/gcc-trunk/gcc/ira.cc:5940 0x1161129 execute /repo/gcc-trunk/gcc/ira.cc:6126 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-7228-20220214143106-g0a1a3afb5fb-checking-yes-rtl-df-extra-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 --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-7228-20220214143106-g0a1a3afb5fb-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220214 (experimental) (GCC)
[Bug target/104540] New: ICE: SIGSEGV in cfi_oprnd_equal_p with -O2 -fharden-conditional-branches -mforce-drap -mstackrealign --param=max-grow-copy-bb-insns=125
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104540 Bug ID: 104540 Summary: ICE: SIGSEGV in cfi_oprnd_equal_p with -O2 -fharden-conditional-branches -mforce-drap -mstackrealign --param=max-grow-copy-bb-insns=125 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 52442 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52442&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 -fharden-conditional-branches -mforce-drap -mstackrealign --param=max-grow-copy-bb-insns=125 testcase.C during RTL pass: dwarf2 testcase.C: In function 'void foo()': testcase.C:19:1: internal compiler error: Segmentation fault 19 | } | ^ 0x166367f crash_signal /repo/gcc-trunk/gcc/toplev.cc:322 0x11e1770 cfa_reg::operator==(cfa_reg const&) const /repo/gcc-trunk/gcc/dwarf2out.h:144 0x11e1770 cfa_equal_p(dw_cfa_location const*, dw_cfa_location const*) /repo/gcc-trunk/gcc/dwarf2cfi.cc:765 0x11e1a99 cfi_row_equal_p /repo/gcc-trunk/gcc/dwarf2cfi.cc:831 0x11e534a maybe_record_trace_start /repo/gcc-trunk/gcc/dwarf2cfi.cc:2565 0x11e590b create_trace_edges /repo/gcc-trunk/gcc/dwarf2cfi.cc:2679 0x11e5f16 scan_trace /repo/gcc-trunk/gcc/dwarf2cfi.cc:2903 0x11e7303 create_cfi_notes /repo/gcc-trunk/gcc/dwarf2cfi.cc:2930 0x11e7303 execute_dwarf2_frame /repo/gcc-trunk/gcc/dwarf2cfi.cc:3301 0x11e7303 execute /repo/gcc-trunk/gcc/dwarf2cfi.cc:3789 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-7228-20220214143106-g0a1a3afb5fb-checking-yes-rtl-df-extra-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 --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-7228-20220214143106-g0a1a3afb5fb-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220214 (experimental) (GCC)
[Bug c++/104107] [9/10/11/12 Regression] parsing crashes on class template instantiation since r9-6853-g17838af989014f5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104107 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2c3309e3d0f5cb8f298f7604848d115f0992e04f commit r12-7236-g2c3309e3d0f5cb8f298f7604848d115f0992e04f Author: Jason Merrill Date: Thu Feb 10 17:57:38 2022 -0500 c++: TTP in member alias template [PR104107] In the first testcase, coerce_template_template_parms was adding too much of outer_args when coercing to match P's template parameters, so that when substituting into the 'const T&' parameter we got an unrelated template argument for T. We should only add outer_args when the argument template is a nested template. PR c++/104107 PR c++/95036 gcc/cp/ChangeLog: * pt.cc (coerce_template_template_parms): Take full parms. Avoid adding too much of outer_args. (coerce_template_template_parm): Adjust. (template_template_parm_bindings_ok_p): Adjust. (convert_template_argument): Adjust. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/alias-decl-ttp2.C: New test. * g++.dg/cpp1z/ttp2.C: New test.
[Bug c++/95036] [9/10/11/12 Regression] ICE with variadic template template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95036 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2c3309e3d0f5cb8f298f7604848d115f0992e04f commit r12-7236-g2c3309e3d0f5cb8f298f7604848d115f0992e04f Author: Jason Merrill Date: Thu Feb 10 17:57:38 2022 -0500 c++: TTP in member alias template [PR104107] In the first testcase, coerce_template_template_parms was adding too much of outer_args when coercing to match P's template parameters, so that when substituting into the 'const T&' parameter we got an unrelated template argument for T. We should only add outer_args when the argument template is a nested template. PR c++/104107 PR c++/95036 gcc/cp/ChangeLog: * pt.cc (coerce_template_template_parms): Take full parms. Avoid adding too much of outer_args. (coerce_template_template_parm): Adjust. (template_template_parm_bindings_ok_p): Adjust. (convert_template_argument): Adjust. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/alias-decl-ttp2.C: New test. * g++.dg/cpp1z/ttp2.C: New test.
[Bug ipa/102513] [10/11/12 Regression] Many false positive warnings with recursive function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513
--- Comment #10 from Feng Xue ---
(In reply to Martin Jambor from comment #8)
> I am about to thest the following patch. In longer-run, it would be better
> to never generate lattice values outside of the value_range but there is an
> ordering problem, we need the complete VR info before we can use it. I plan
> to rearrange IPA-CP into making multiple passes over the lattice dependency
> graph and this should quite naturally be solved by doing this kind of
> resursive-value-generation only in second and later passes.
>
>
> diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
> index 453e9c93cc3..cbbb8bbc80a 100644
> --- a/gcc/ipa-cp.cc
> +++ b/gcc/ipa-cp.cc
> @@ -6154,8 +6154,16 @@ decide_whether_version_node (struct cgraph_node *node)
> {
> ipcp_value *val;
> for (val = lat->values; val; val = val->next)
> - ret |= decide_about_value (node, i, -1, val, &avals,
> - &self_gen_clones);
> + {
> + if (!plats->m_value_range.bottom_p ()
> + && !plats->m_value_range.m_vr.contains_p (val->value))
> + {
> + gcc_checking_assert (val->self_recursion_generated_p ());
> + continue;
> + }
> + ret |= decide_about_value (node, i, -1, val, &avals,
> +&self_gen_clones);
> + }
> }
>
>if (!plats->aggs_bottom)
Here is a complication that value range for recursion index might not be not
easily computed, and could not prevent IPA-CP generating useless copy.
Constraint of recursion index comes from "block2[level][x]", not its value
range deduced from condition predicate (level > 0). Change the case to cover up
value range of "level", and we will get same warning. So in the circumstances,
one way for us is to disable warning for these copies?
extern int block2[7][256];
extern unsigned G_START;
extern unsigned G_SCALE;
static int encode_block(int block2[7][256], unsigned level)
{
int best_score = 0;
for (unsigned x = G_START; x < G_SCALE * level; x++) {
int v = block2[1][x];
block2[level][x] = 0;
best_score += v * v;
}
if (G_SCALE * level > G_START && best_score > 64) {
int score = 0;
score += encode_block(block2, level - 1);
score += encode_block(block2, level - 1);
if (score < best_score) {
best_score = score;
}
}
return best_score;
}
[Bug tree-optimization/104539] Failed to inline a very simple template function when it's explicit instantiated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104539
--- Comment #1 from Cassio Neri ---
Sorry, the last snippet above should be
template
inline
int f() {
return 0;
}
[Bug tree-optimization/104539] New: Failed to inline a very simple template function when it's explicit instantiated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104539
Bug ID: 104539
Summary: Failed to inline a very simple template function when
it's explicit instantiated.
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: cassio.neri at gmail dot com
Target Milestone: ---
Consider:
template
//inline
int f() {
return 0;
}
int g() {
return f<0>() + 1;
}
Using -O3, I'd expect f to be inlined in g and this is indeed the case:
g():
mov eax, 1
ret
However, if f is explicit instantiated:
template unsigned f<0>();
then we get a function call (or a jmp if tail call optimisation is possible)
g():
sub rsp, 8
call int f<0>()
add rsp, 8
add eax, 1
ret
A (quite unusual, IMHO) workaround is declaring f as inline:
template
inline
unsigned f() {
return n;
}
https://godbolt.org/z/TarsTY3zb
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 Randy changed: What|Removed |Added CC||Randy at miningrigrentals dot com --- Comment #34 from Randy --- Is the patch for GCC 12 for this issue also applied to std_vstring?
[Bug d/104538] gdc/d21: segfault on mips64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104538 --- Comment #1 from YunQiang Su --- This problem happens only for the new gdc code introduced in gcc-12.
[Bug d/104538] New: gdc/d21: segfault on mips64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104538
Bug ID: 104538
Summary: gdc/d21: segfault on mips64
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: syq at debian dot org
Target Milestone: ---
https://buildd.debian.org/status/fetch.php?pkg=gcc-12&arch=mips64el&ver=12-20220214-1&stamp=1644848228&raw=0
The segment is from:
gcc/d/dmd/ctfeexpr.d:
UnionExp changeArrayLiteralLength(const ref Loc loc, TypeArray arrayType,
Expression oldval, size_t oldlen, size_t newlen)
if (oldlen != 0)
{
assert(oldval.op == EXP.arrayLiteral);
ArrayLiteralExp ae = cast(ArrayLiteralExp)oldval;
foreach (size_t i; 0 .. copylen)
(*elements)[i] = (*ae.elements)[indxlo + i];
}
if (elemType.ty == Tstruct || elemType.ty == Tsarray)
{
/* If it is an aggregate literal representing a value type,
* we need to create a unique copy for each element
*/
foreach (size_t i; copylen .. newlen)
(*elements)[i] = copyLiteral(defaultElem).copy();
}
else
{
foreach (size_t i; copylen .. newlen)
(*elements)[i] = defaultElem;
}
>>>>emplaceExp!(ArrayLiteralExp)(&ue, loc, arrayType, elements);
ArrayLiteralExp aae = cast(ArrayLiteralExp)ue.exp();
aae.ownedByCtfe = OwnedBy.ctfe;
[Bug ipa/104377] Unreachable code in create_specialized_node of ipa-prop.c?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104377 --- Comment #4 from Feng Xue --- (In reply to Martin Jambor from comment #2) > (In reply to Feng Xue from comment #1) > > > > OK. I does missed something. Here we could not hold assumption that > > ipcp_decision_stage() only sees raw cgraph node, since sometime in the > > future some new ipa pass may be added prior to ipa-cp, and this pass > > introduces clone node. > > Right, initially IPA-SRA was developed as a pass before IPA-CP and it > may well be that we decide to swap the order again. > > > > > However, there is a questionable point about the code snippet > > > > if (!node->can_change_signature > > || old_adj->op != IPA_PARAM_OP_COPY > > || (!known_csts[old_adj->base_index] > > && ipa_is_param_used (info, old_adj->base_index))) > > > > In ipa-cp, known_csts is for the node, has no relation to the node's origin > > node, but here it is accessed via index of the latter (old_adj->base_index), > > will this cause out-of-bound error? > > I think the code is correct. Assume IPA-SRA running before IPA-CP, and > we're compiling a function with two argument, with indices 0 and 1. > > Analysis phases of both passes run before the IPA (WPA) phases of > either. This is important to keep in mind. > > IPA SRA removes the first one with index zero as useless, IPA-CP wants > to remove the second one with index 1, possibly because it is constant > everywhere. In oder to that it has to combine the pre-existing > adjustments with its own changes. > > Before create_specialized_node, the pass checks whether previous > passes did not kill some parameters and stops caring about them, but > it does not re-index anything, all lattices, jump functions, > everything, still keep their positions (and thus indices) they got in > the analysis phase. > > Then create_specialized_node hits this loop. For i=0 encounters an > old_adj element that actually describes the parameter which originally > had index 1. The pass looks up in base_index what the original > (pre-IPA) index of the parameter was (1) and uses those to look up in > its own structures whether it wants to remove it or not. > > Bounds should be always OK, base_index should never be greater than > the original pre-IPA number of parameters (-1) and known_csts should > always have just as many parameters. > > Does that make sense? Yes. Thanks for your explanation.
[Bug c++/99215] coroutines: debugging with gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215 --- Comment #14 from Jarrod Smith --- I've been following this and experiencing the issue in gcc 10.2. I still see "" for all variables when debugging C++20 coroutines with gcc 11.2. Is there a workaround (e.g. using a certain branch of gcc) in order to inspect coroutine variables with gdb the meantime?
[Bug c++/104537] New: ICE when generic-lambda as function parameter fails to be converted to pointer to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104537
Bug ID: 104537
Summary: ICE when generic-lambda as function parameter fails to
be converted to pointer to function
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
Consider this invalid conversion for this generic-lambda to pointer to function
which is defined by "decltype(+[](T&& t )->T{return t+1;}".
This ICE happens when original accepted parameter type changed from "T" to
"T&&".
See compiler explorer (https://www.godbolt.org/z/fde1bc3zE)
I suspect this is some related issue with another unconfirmed case PR104358.
template
auto foo(T&& t, decltype(+[](T&& t )->T{return t+1;}) lam){
return lam(t);
}
void test(){
foo(5, [](int t){return t+1;});
}
:8:21: error: invalid user-defined conversion from
'test()::' to 'int (*)(int&&)' [-fpermissive]
8 | foo(5, [](int t){return t+1;});
| ^~
...
internal compiler error: error reporting routines re-entered.
0x2174365 warning_at(unsigned int, int, char const*, ...)
...
[Bug middle-end/104492] [12 Regression] Bogus dangling pointer warning at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104492
--- Comment #5 from Martin Sebor ---
Setting aside the question of warning about inequality expressions involving
invalid pointers, it seems that if the annotation 'candidates ={v}
{CLOBBER(eol)};' is to be interpreted as one would intuitively expect -- as
ending the variable's lifetime -- then GCC moving its use past that point
should be considered a bug in that transformation.
[Bug target/99197] Built-ins for packing/unpacking __ibm128 not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99197
Michael Meissner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Michael Meissner ---
These functions have been documented since June 2018. The file extend.texi
contains:
The @code{__builtin_unpack_ibm128} function takes a @code{__ibm128}
argument and a compile time constant of 0 or 1. If the constant is 0,
the first @code{double} within the @code{__ibm128} is returned,
otherwise the second @code{double} is returned.
The @code{__builtin_pack_ibm128} function takes two @code{double}
arguments and returns a @code{__ibm128} value that combines the two
arguments.
[Bug other/104536] [12 Regression] gcc-12-20220213 Fails to build on Cygwin: contraction ‘can%'t’ in format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104536 Andrew Pinski changed: What|Removed |Added Component|bootstrap |other Host||*-*-cygwin Summary|gcc-12-20220213 Fails to|[12 Regression] |build on Cygwin:|gcc-12-20220213 Fails to |contraction ‘can%'t’ in |build on Cygwin: |format |contraction ‘can%'t’ in ||format Target Milestone|--- |12.0 Keywords||build, diagnostic
[Bug bootstrap/104536] gcc-12-20220213 Fails to build on Cygwin: contraction ‘can%'t’ in format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104536 --- Comment #1 from James McKelvey --- Created attachment 52441 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52441&action=edit Config log
[Bug bootstrap/104536] New: gcc-12-20220213 Fails to build on Cygwin: contraction ‘can%'t’ in format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104536 Bug ID: 104536 Summary: gcc-12-20220213 Fails to build on Cygwin: contraction ‘can%'t’ in format Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mckelvey at maskull dot com Target Milestone: --- Created attachment 52440 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52440&action=edit Log of entire build Building on Cygwin with gcc-11-20220212 and Windows 10. ./configure --enable-languages=c,c++ --enable-threads=posix --disable-multilib $ uname CYGWIN_NT-10.0 make[3]: Entering directory '/home/McKelvey/gcc-12-20220213/host-x86_64-pc-cygwin/gcc' /home/McKelvey/gcc-12-20220213/host-x86_64-pc-cygwin/prev-gcc/xg++ -B/home/McKelvey/gcc-12-20220213/host-x86_64-pc-cygwin/prev-gcc/ -B/usr/local/x86_64-pc-cygwin/bin/ -nostdinc++ -B/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/src/.libs -B/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs -I/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin -I/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/include -I/home/McKelvey/gcc-12-20220213/libstdc++-v3/libsupc++ -L/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/src/.libs -L/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libcody -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid -I../libdecnumber -I../.././gcc/../libbacktrace -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libcody -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid -I../libdecnumber -I../.././gcc/../libbacktrace \ ../.././gcc/config/i386/host-cygwin.cc ../.././gcc/config/i386/host-cygwin.cc: In function ‘void* cygwin_gt_pch_get_address(size_t, int)’: ../.././gcc/config/i386/host-cygwin.cc:57:35: error: contraction ‘can%'t’ in format; use ‘cannot’ instead [-Werror=format-diag] 57 | fatal_error (input_location, "can%'t get position in PCH file: %m"); | ^~ ../.././gcc/config/i386/host-cygwin.cc:64:37: error: contraction ‘can%'t’ in format; use ‘cannot’ instead [-Werror=format-diag] 64 | fatal_error (input_location, "can%'t extend PCH file: %m"); | ^~ ../.././gcc/config/i386/host-cygwin.cc:75:35: error: contraction ‘can%'t’ in format; use ‘cannot’ instead [-Werror=format-diag] 75 | fatal_error (input_location, "can%'t set position in PCH file: %m"); | ^~ cc1plus: all warnings being treated as errors make[3]: *** [../.././gcc/config/i386/x-cygwin:3: host-cygwin.o] Error 1 make[3]: Leaving directory '/home/McKelvey/gcc-12-20220213/host-x86_64-pc-cygwin/gcc' make[2]: *** [Makefile:5003: all-stage2-gcc] Error 2 make[2]: Leaving directory '/home/McKelvey/gcc-12-20220213' make[1]: *** [Makefile:24127: stage2-bubble] Error 2 make[1]: Leaving directory '/home/McKelvey/gcc-12-20220213' make: *** [Makefile:1072: all] Error 2
[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 --- Comment #9 from qinzhao at gcc dot gnu.org --- having a patch in my local tree, under testing.
[Bug middle-end/104355] Misleading -Warray-bounds documentation says "always out of bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104355 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:7a1b179b08bc802280ca90ed4c6c8d8b25503e66 commit r12-7234-g7a1b179b08bc802280ca90ed4c6c8d8b25503e66 Author: Martin Sebor Date: Mon Feb 14 15:40:25 2022 -0700 Update -Warray-bounds documentation [PR104355]. Resolves: PR middle-end/104355 - Misleading and outdated -Warray-bounds documentation gcc/ChangeLog: PR middle-end/104355 * doc/invoke.texi (-Warray-bounds): Update documentation.
[Bug target/104253] libgcc missing __floatdiif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253 --- Comment #12 from CVS Commits --- The master branch has been updated by Michael Meissner : https://gcc.gnu.org/g:16b65b08484237cc2845c4f5c4f15efe3a43a32c commit r12-7233-g16b65b08484237cc2845c4f5c4f15efe3a43a32c Author: Michael Meissner Date: Mon Feb 14 17:42:14 2022 -0500 Use correct names for __ibm128 if long double is IEEE 128-bit. If you are on a PowerPC system where the default long double is IEEE 128-bit (either through the compiler option -mabi=ieeelongdouble or via the configure option --with-long-double-format=ieee), GCC used the wrong names for some of the conversion functions for the __ibm128 type. Internally, GCC uses IFmode for __ibm128 if long double is IEEE 128-bit, instead of TFmode when long double is IBM 128-bit. This patch adds the missing conversions to prevent the 'if' name from being used. In particular, before the patch, the conversions used were: IFmode to DImode signed:__fixifdi instead of __fixtfdi IFmode to DImode unsigned __fixunsiftiinstead of __fixunstfti DImode to IFmode signed:__floatdiif instead of __floatditf DImode to IFmode unsigned: __floatundiif instead of __floatunditf 2022-02-14 Michael Meissner gcc/ PR target/104253 * config/rs6000/rs6000.cc (init_float128_ibm): Update the conversion functions used to convert IFmode types. gcc/testsuite/ PR target/104253 * gcc.target/powerpc/pr104253.c: New test.
[Bug tree-optimization/104526] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104526 --- Comment #3 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #2) > and evrp properly figured out those ranges, that 1 / int is [-1, 1] and > that 2 >> [-1, 1] is [1, 2]. > But since r12-6924 the IL is: > c.0_1 = c; > _2 = *c.0_1; > _11 = (unsigned int) _2; > _12 = _11 + 1; > _13 = _12 <= 2; > _3 = _12 <= 2 ? _2 : 0; > So, Andrew/Aldy, how hard would it be to improve ranger COND_EXPR handling, > so that it essentially does what we do for the PHI cases? I.e. from the > COND_EXPR condition, compute "assertion" if condition is true or if > condition is false, and use that on the COND_EXPR's second and third > argument. > So for the > _3 = _12 <= 2 ? _2 : 0; > comparison, for second argument the condition must be true which implies that > _2 must be there [-1, 1], while for the third argument the condition must be > false, but the argument is constant 0, so range is [0, 0], then just union > those 2 ranges. > > As this is a P1 regression, if we can fix it, would be nice to get it into > GCC 12. I'm having a look. The bits are all there. Most of gori is stmt oriented, but I may be able to invoke the components such that we evaluate the 2nd and 3rd arguemnts as if they were on true/false edges to improve the results..
[Bug c++/104523] G++ crash when compiling a simple module that includes pybind11/stl.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104523
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Ever confirmed|0 |1
Last reconfirmed|2022-02-13 00:00:00 |2022-02-14
Status|UNCONFIRMED |NEW
--- Comment #4 from Andrew Pinski ---
Confirmed, reduced testcase:
# 1 "mysource.cc"
module ;
# 1 "myheader.h" 1
template
class t {
template friend class tt;
};
t to_wstring() { }
# 4 "mysource.cc" 2
export module mymodule;
Or maybe that is a regression from before
[Bug fortran/104535] New: don't use fmod?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104535 Bug ID: 104535 Summary: don't use fmod? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fx at gnu dot org Target Milestone: --- I was reminded by comments on the report I made about poor fmod performance on x86 that I should have commented on the original observation. I'd looked at one of the Polyhedron benchmarks which suffers badly from a simple random number routine that calls DMOD. That gets compiled to fmod, which is only inlined, albeit poorly on x86, with the relevant component(s) of -ffast-math. It seems to me that MOD should compile to the arithmetical expression in the standard, which doesn't have the complication of having to treat errors. (When I defined DMOD as a statement function for it in that routine, I got performance much closer to ifort. I should have kept the profiles I compared, but could regenerate them. Is there a good reason not to do that (and maybe similarly with other intrinsics I haven't checked)? I could probably have a go at implementing it if appropriate, though I don't know my way around now.
[Bug c++/95596] string literal wrong overload resolution (char* vs std::string)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95596 Andrew Pinski changed: What|Removed |Added CC||johnsen.david at siemens dot com --- Comment #7 from Andrew Pinski --- *** Bug 104534 has been marked as a duplicate of this bug. ***
[Bug c++/104534] write-strings does not follow C++ standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104534 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 95596. *** This bug has been marked as a duplicate of bug 95596 ***
[Bug fortran/104211] ICE in find_array_section, at fortran/expr.cc:1720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104211 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:19b517dff37b8e25f6babf8883483be73cad8fb3 commit r12-7232-g19b517dff37b8e25f6babf8883483be73cad8fb3 Author: Harald Anlauf Date: Thu Feb 10 21:22:48 2022 +0100 Fortran: improve error recovery on bad array section gcc/fortran/ChangeLog: PR fortran/104211 * expr.cc (find_array_section): Replace assertion by error recovery when encountering bad array constructor. gcc/testsuite/ChangeLog: PR fortran/104211 * gfortran.dg/pr104211.f90: New test.
[Bug c++/104534] New: write-strings does not follow C++ standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104534
Bug ID: 104534
Summary: write-strings does not follow C++ standard
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johnsen.david at siemens dot com
Target Milestone: ---
The bug is present in all versions of GCC from 6 to 11 and on GCC trunk.
example file ws.cpp:
#include
void f(char*) { std::cout << "This compiler is broken" << std::endl; }
void f(bool) { std::cout << "This compiler is correct" << std::endl; }
int main() {
f("This is supposed to work");
return 0;
}
This program is a valid C++ and the standard is very clear on what the result
should be.
As far as I know, there is no way to make GCC generate this result.
compiled with: c++ ws.cpp
Depending on the command line options, the program can:
* compile (and run incorrectly, -Wnowrite-strings),
* compile with a warning (still run incorrectly, -Wwrite-strings),
* or not compile at all (-Werror -Wwrite-strings).
The only outcome that I can't get is the correct one:
* The program compiles without errors and runs correctly.
Other compilers, such as clang++ and Visual Studio C++, follow the standard.
[Bug c/104531] [12 Regression] ICE in prepare_cmp_insn, at optabs.cc:4547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104531 Andrew Pinski changed: What|Removed |Added Component|middle-end |c Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #1 from Andrew Pinski --- I think this might be invalid code. The C++ front-end does: : In function 'void f(__complex__ int, int)': :3:11: error: invalid operands of types 'int' and '__complex__ int' to binary '' 3 | #pragma omp atomic compare update seq_cst | ^~~ :3:11: note: in evaluation of '(int, __complex__ int)' Without -fopenmp we get: : In function 'f': :4:9: error: invalid operands to binary > (have 'int' and 'complex int') 4 | x = x > y ? y : x; | ^
[Bug c++/104533] New: [12 Regression] ICE in update_vtable_references, at ipa-visibility.cc:383
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104533
Bug ID: 104533
Summary: [12 Regression] ICE in update_vtable_references, at
ipa-visibility.cc:383
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 2024 and 20211121 :
$ cat z1.cc
struct B {
virtual ~B();
};
__attribute__((target_clones("avx")))
B::~B() = default;
$ cat z2.cc
struct B {
virtual ~B();
};
__attribute__((target_clones("sse","avx")))
B::~B() = default;
$ g++-12-20220213 -c z1.cc -fPIC -Ofast
during IPA pass: visibility
z1.cc:5:18: internal compiler error: Segmentation fault
5 | B::~B() = default;
| ^
0xda1fdf crash_signal
../../gcc/toplev.cc:322
0x19be64f update_vtable_references
../../gcc/ipa-visibility.cc:383
0x1029952 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11070
0x1029b9c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.cc:11157
0x19bf549 function_and_variable_visibility
../../gcc/ipa-visibility.cc:868
[Bug middle-end/104531] [12 Regression] ICE in prepare_cmp_insn, at optabs.cc:4547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104531 Andrew Pinski changed: What|Removed |Added Summary|ICE in prepare_cmp_insn, at |[12 Regression] ICE in |optabs.cc:4547 |prepare_cmp_insn, at ||optabs.cc:4547 Keywords||ice-on-valid-code Target Milestone|--- |12.0 Component|c |middle-end
[Bug c/104532] New: ICE in lvalue_p, at c/c-typeck.cc:4987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104532
Bug ID: 104532
Summary: ICE in lvalue_p, at c/c-typeck.cc:4987
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20211205 and 20211212 :
$ cat z1.c
void f (int x)
{
#pragma omp target enter data map (to: x->vectors)
}
$ cat z2.c
void f (int x)
{
#pragma omp target enter data map (to: x->vectors[])
}
$ gcc-12-20220213 -c z1.c -fopenmp
z1.c: In function 'f':
z1.c:3:11: internal compiler error: Segmentation fault
3 | #pragma omp target enter data map (to: x->vectors)
| ^~~
0xc1c3cf crash_signal
../../gcc/toplev.cc:322
0x6c1a46 lvalue_p(tree_node const*)
../../gcc/c/c-typeck.cc:4987
0x6ca5a8 build_component_ref(unsigned int, tree_node*, tree_node*, unsigned
int)
../../gcc/c/c-typeck.cc:2470
0x6f742e c_parser_omp_variable_list
../../gcc/c/c-parser.cc:13161
0x6f81dc c_parser_omp_clause_map
../../gcc/c/c-parser.cc:16260
0x700262 c_parser_omp_all_clauses
../../gcc/c/c-parser.cc:17057
0x70d6ae c_parser_omp_target_enter_data
../../gcc/c/c-parser.cc:20904
0x70d6ae c_parser_omp_target
../../gcc/c/c-parser.cc:21195
0x6e7a44 c_parser_pragma
../../gcc/c/c-parser.cc:12499
0x7054a6 c_parser_compound_statement_nostart
../../gcc/c/c-parser.cc:5767
0x705873 c_parser_compound_statement
../../gcc/c/c-parser.cc:5609
0x707128 c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:2544
0x70e85f c_parser_external_declaration
../../gcc/c/c-parser.cc:1779
0x70f18b c_parser_translation_unit
../../gcc/c/c-parser.cc:1652
0x70f18b c_parse_file()
../../gcc/c/c-parser.cc:23348
0x760792 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1238
[Bug c/104531] New: ICE in prepare_cmp_insn, at optabs.cc:4547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104531
Bug ID: 104531
Summary: ICE in prepare_cmp_insn, at optabs.cc:4547
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20210905 and 20210919 :
$ cat z1.c
void f (_Complex int y, int x)
{
#pragma omp atomic compare update seq_cst
x = x > y ? y : x;
}
$ gcc-12-20220213 -c z1.c -fopenmp
during RTL pass: expand
z1.c: In function 'f':
z1.c:3:11: internal compiler error: in prepare_cmp_insn, at optabs.cc:4547
3 | #pragma omp atomic compare update seq_cst
| ^~~
0xafd677 prepare_cmp_insn
../../gcc/optabs.cc:4547
0xafd711 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, profile_probability)
../../gcc/optabs.cc:4692
0x839688 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, profile_probability)
../../gcc/dojump.cc:1220
0x8df4a5 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.cc:9745
0x7c4ea2 expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3967
0x7c4ea2 expand_gimple_stmt
../../gcc/cfgexpand.cc:4028
0x7c9bd7 expand_gimple_basic_block
../../gcc/cfgexpand.cc:6069
0x7cc67e execute
../../gcc/cfgexpand.cc:6795
[Bug target/104529] [12 Regression] inefficient codegen around new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #4 from Andrew Pinski --- (In reply to Tamar Christina from comment #3) > I'm re-opening because I don't think it has anything to do with #94294 > > This is a GCC 12 regression. > > In GCC 11 we generated in the mid-end > ... > and in GCC 12 we now generate > ... > > See https://godbolt.org/z/KKfhxTxnd > > Forcing it to keep the stores before the call to new. Hmm, I should have looked into the code before marking it as a dup.
[Bug target/104529] [12 Regression] inefficient codegen around new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
Tamar Christina changed:
What|Removed |Added
Summary|[missed optimization] |[12 Regression] inefficient
|inefficient codegen around |codegen around new/delete
|new/delete |
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE |---
--- Comment #3 from Tamar Christina ---
I'm re-opening because I don't think it has anything to do with #94294
This is a GCC 12 regression.
In GCC 11 we generated in the mid-end
[local count: 536870913]:
_32 = operator new (6);
MEM [(char * {ref-all})_32] = 255;
MEM [(char * {ref-all})_32 + 4B] = 0;
operator delete (_32, 6);
return 56;
and in GCC 12 we now generate
[local count: 536870913]:
MEM [(unsigned char *)&D.24688] = { 255, 0, 0, 0 };
MEM [(unsigned char *)&D.24688 + 4B] = { 0, 0 };
_34 = operator new (6);
MEM [(char * {ref-all})_34] = MEM
[(char * {ref-all})&D.24688];
D.24688 ={v} {CLOBBER(eol)};
operator delete (_34, 6);
return 56;
See https://godbolt.org/z/KKfhxTxnd
Forcing it to keep the stores before the call to new.
[Bug target/104529] [missed optimization] inefficient codegen around new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
--- Comment #2 from Tamar Christina ---
I don't quite see how this is a CSE problem,
There's only one of each constant and none of them are needed before the call.
unlike in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86892
You don't need the values of your array until you allocate memory for said
array.
x86 has the following sequence in GIMPLE
_32 = operator new (6);
MEM [(char * {ref-all})_32] = 255;
MEM [(char * {ref-all})_32 + 4B] = 0;
operator delete (_32, 6);
which is optimal, you create the object, store the values, and remove it.
AArch64 however has this
MEM [(unsigned char *)&D.24688] = 255;
MEM [(unsigned char *)&D.24688 + 4B] = 0;
_34 = operator new (6);
MEM [(char * {ref-all})_34] = MEM
[(char * {ref-all})&D.24688];
D.24688 ={v} {CLOBBER(eol)};
operator delete (_34, 6);
which is where the issue comes from. So this has nothing to do with CSE as far
as I can tell. The GIMPLE is just suboptimal.
[Bug ipa/103083] [10/11/12 Regression] Wrong code due to ipa-cp's bits value propagation since r10-5538-gc7ac9a0c7e3916f1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083 --- Comment #5 from Martin Jambor --- I have changed the patch a bit and re-submitted for review: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590341.html
[Bug ipa/102513] [10/11/12 Regression] Many false positive warnings with recursive function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Component|tree-optimization |ipa --- Comment #9 from Martin Jambor --- The patch had to be tweaked a bit but I have proposed the following one on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590371.html
[Bug rtl-optimization/104154] [12 Regression] Another ICE due to recent ifcvt changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154 --- Comment #8 from Jeffrey A. Law --- So the updated patch fixes the arc build regressions. I haven't looked at the thread with Segher, but I will as soon as I can. Mostly just wanted to let you know that the updated patch does indeed get the port building again.
[Bug c/104510] [9/10/11/12 Regression] ICE: 'verify_gimple' failed: mismatching comparison operand types in verify_gimple_in_seq()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104510 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Jakub Jelinek --- Created attachment 52439 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52439&action=edit gcc12-pr104510.patch Untested fix. Callers don't expect shorten_compare to ever fail, even when it returns NULL it still should convert arguments at least to the original *restype_ptr.
[Bug rtl-optimization/86892] RTL CSE commoning trivial constants across call and/or too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86892 Andrew Pinski changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- *** Bug 104529 has been marked as a duplicate of this bug. ***
[Bug target/104529] [missed optimization] inefficient codegen around new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 86892. *** This bug has been marked as a duplicate of bug 86892 ***
[Bug c++/104008] [11/12 Regression] New g++ folly compile error with gcc 11.x. Bisected to PR99445 c++: Alias template in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008 Aleksei Latyshev changed: What|Removed |Added CC||alex_700_95 at mail dot ru --- Comment #6 from Aleksei Latyshev --- Let me add a simplified reproducer for this bug: https://godbolt.org/z/3ec1dW8YE
[Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #13 from Jonathan Wakely --- Fixed on trunk now. As this adds new symbol versions I don't plan to backport it to gcc-11. Trunk should be used for anybody who needs IEEE128 support.
[Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912 --- Comment #12 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3d50dede07de0923f0f320d385162e546445e640 commit r12-7231-g3d50dede07de0923f0f320d385162e546445e640 Author: Jonathan Wakely Date: Mon Feb 14 16:46:55 2022 + libstdc++: Fix stream extraction of IEEE128 long double [PR100912] The std::__convert_from_v helper that formats double and long double values into a char buffer was not being duplicated for the two long double ABIs. This resulted in an ODR violation inside the library, where some callers needed it to use snprintf to format __ibm128 values and other callers needed it to use __snprintfieee128 to format __ieee128 values. The linker discarded one of the definitions, leaving one set of callers using the wrong code. This puts __convert_from_v in the __gnu_cxx_ieee128 inline namespace when long double is __ieee128, so that there are two different definitions of the function. The std::money_put::__do_put overload for __ibm128 values needs a different fix, because that is defined when long double is __ieee128 and so would call the one in the inline namespace. That can be fixed by just inlining the code directly into the function and using an asm alias to call the right version of snprintf for the __ibm128 format. The code to do that can be simpler than __convert_from_v because if we're defining the ALT128_COMPAT symbols we know that we have a recent glibc and so we can assume that uselocale and snprintf are supported. libstdc++-v3/ChangeLog: PR libstdc++/100912 * config/locale/gnu/c_locale.h (__convert_from_v): Use inline namespace for IEEE128 long double mode. * config/os/gnu-linux/ldbl-ieee128-extra.ver: Add new symbol version and export __gnu_cxx_ieee128::__convert_from_v. * include/bits/locale_facets_nonio.tcc (money_put::__do_put): Make __ibm128 overload use snprintf directly * testsuite/util/testsuite_abi.cc: Add new symbol version. Remove stable IEEE128/LDBL versions.
[Bug libstdc++/100806] deadlock in std::counting_semaphore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100806 Thomas Rodgers changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Thomas Rodgers --- I believe this has been fully resolved.
[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 --- Comment #8 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #7) > If we just want to avoid the warning in cases like that (there is nothing > wrong in the testcases themselves, the warning just warns about an > implementation detail that a normally uninitialized variable will be really > uninitialized even despite the -ftrivial-auto-var-init= option), then > maybe_warn_switch_unreachable > already has: > if (gimple_code (stmt) == GIMPLE_GOTO > && TREE_CODE (gimple_goto_dest (stmt)) == LABEL_DECL > && DECL_ARTIFICIAL (gimple_goto_dest (stmt))) > /* Don't warn for compiler-generated gotos. These occur >in Duff's devices, for example. */; > and so for flag_auto_var_init > AUTO_INIT_UNINITIALIZED perhaps we could also > avoid warnings on: > 1) call to .DEFERRED_INIT > 2) call to __builtin_clear_padding if the second argument is present and > non-zero > 3) I guess we would need not to warn on a gimple assign store right after > the .DEFERRED_INIT call that has the lhs of .DEFERRED_INIT as rhs > anything else? Yes, I think the above 3 should include all the cases.
[Bug c++/104507] [10/11/12 Regression] internal compiler error: unexpected expression ‘(int)(__ret)’ of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104507
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|[10/11 Regression] internal |[10/11/12 Regression]
|compiler error: unexpected |internal compiler error:
|expression ‘(int)(__ret)’ |unexpected expression
|of kind cast_expr |‘(int)(__ret)’ of kind
||cast_expr
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-02-14
Known to fail||12.0
--- Comment #6 from Patrick Palka ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Daniel Nelson from comment #2)
> > Had a few moments to do some testing/bisecting, and found the commit that
> > fixed this in mainline.
>
> I kinda of see how that might help here but not really. I wonder if there is
> another testcase which might shows the issue on the trunk still.
trunk crashes on this version:
#define ERR_MAX -20
#define s_errmsg(r) \
_k_errmsg[(((int)r) <= 0 && r) ? -(r) : -ERR_MAX]
extern const char *_k_errmsg[];
template
inline int DoFoo() {
int __ret = 0;
const char *n = s_errmsg(__ret);
return __ret;
}
[Bug tree-optimization/104530] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104530 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |12.0 CC||jakub at gcc dot gnu.org Priority|P3 |P1 --- Comment #1 from Jakub Jelinek --- Started with r12-7128-gc6bb1db76b3ac127aff7dacf391fc1798a94bb7d The comparison is done before dereferencing pointer, but unlike the PR104288 case there is no call that could fail to return in between. I think PR104288 has been fixed on the 11 branch too, so the question is if this still works there.
[Bug tree-optimization/104530] New: [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104530
Bug ID: 104530
Summary: [12 Regression] Dead Code Elimination Regression at
-O3 (trunk vs. 11.2.0)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
Dead Code Elimination Regression at -O3 (trunk vs.
a7fede6704dd207fb32b97bc30f945acc7b953c5) 138751
---
cat case.c #138751
void foo(void);
static int a, *b = &a, c, d = 1;
int main() {
c = 0 == b;
a = *b;
if (c % d)
for (; d; --d)
foo();
b = 0;
}
gcc-58aeb75d4097010ad9bb72b964265b18ab284f93 (trunk) -O3 can not eliminate foo
but gcc-11.2.0 -O3 can.
gcc-58aeb75d4097010ad9bb72b964265b18ab284f93 (trunk) -O3 -S -o /dev/stdout
case.c
- OUTPUT -
main:
.LFB0:
.cfi_startproc
movqb(%rip), %rax
testq %rax, %rax
movl(%rax), %edx
sete%al
movzbl %al, %eax
movl%edx, a(%rip)
cltd
idivl d(%rip)
testl %edx, %edx
je .L9
pushq %rax
.cfi_def_cfa_offset 16
.p2align 4,,10
.p2align 3
.L3:
callfoo
subl$1, d(%rip)
jne .L3
xorl%ecx, %ecx
xorl%eax, %eax
movq%rcx, b(%rip)
popq%rsi
.cfi_def_cfa_offset 8
ret
.L9:
xorl%edx, %edx
xorl%eax, %eax
movq%rdx, b(%rip)
ret
-- END OUTPUT -
gcc-11.2.0 -O3 -S -o /dev/stdout case.c
- OUTPUT -
main:
.LFB0:
.cfi_startproc
movqb(%rip), %rax
movq$0, b(%rip)
movl(%rax), %eax
movl%eax, a(%rip)
xorl%eax, %eax
ret
-- END OUTPUT -
Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c6bb1db76b3ac127aff7dacf391fc1798a94bb7d
- Build information -
- 58aeb75d4097010ad9bb72b964265b18ab284f93 (trunk)
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/compiler_cache/gcc-58aeb75d4097010ad9bb72b964265b18ab284f93
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220213 (experimental) (GCC)
- releases/gcc-11.2.0
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 (GCC)
[Bug c/104510] [9/10/11/12 Regression] ICE: 'verify_gimple' failed: mismatching comparison operand types in verify_gimple_in_seq()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104510 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r5-4736-g1e51d0a29dbfebe6c0df58739562644c1a50f3c3
[Bug c++/104527] [11/12 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104527 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/104527] [11/12 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104527 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P2 CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-02-14 --- Comment #1 from Jakub Jelinek --- ICEs since r11-7454-ge52f8ec25c0e58ebd083e8370e2fbc8af4120d87
[Bug testsuite/104423] [libgomp, testsuite] Add means to do accelerator-only testing in libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104423 --- Comment #5 from Tom de Vries --- Created attachment 52438 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52438&action=edit Tentative patch (GOMP_TARGET_ENV_ITER) A more generic solution using env var GOMP_TARGET_ENV_ITER, which allows us to specify: GOMP_TARGET_ENV_ITER="GOMP_NVPTX_JIT _ -O0".
[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- If we just want to avoid the warning in cases like that (there is nothing wrong in the testcases themselves, the warning just warns about an implementation detail that a normally uninitialized variable will be really uninitialized even despite the -ftrivial-auto-var-init= option), then maybe_warn_switch_unreachable already has: if (gimple_code (stmt) == GIMPLE_GOTO && TREE_CODE (gimple_goto_dest (stmt)) == LABEL_DECL && DECL_ARTIFICIAL (gimple_goto_dest (stmt))) /* Don't warn for compiler-generated gotos. These occur in Duff's devices, for example. */; and so for flag_auto_var_init > AUTO_INIT_UNINITIALIZED perhaps we could also avoid warnings on: 1) call to .DEFERRED_INIT 2) call to __builtin_clear_padding if the second argument is present and non-zero 3) I guess we would need not to warn on a gimple assign store right after the .DEFERRED_INIT call that has the lhs of .DEFERRED_INIT as rhs anything else?
[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104513 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104513 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:02a981a8e512934a990d1427d14e8e884409fade commit r12-7230-g02a981a8e512934a990d1427d14e8e884409fade Author: Jakub Jelinek Date: Mon Feb 14 16:56:15 2022 +0100 c++: Don't reject GOTO_EXPRs to cdtor_label in potential_constant_expression_1 [PR104513] return in ctors on targetm.cxx.cdtor_returns_this () target like arm is emitted as GOTO_EXPR cdtor_label where at cdtor_label it emits RETURN_EXPR with the this. Similarly, in all dtors regardless of targetm.cxx.cdtor_returns_this () a return is emitted similarly. potential_constant_expression_1 was rejecting these gotos and so we incorrectly rejected these testcases, but actual cxx_eval* is apparently handling these just fine. I was a little bit worried that for the destruction of bases we wouldn't evaluate something we should, but as the testcase shows, that is evaluated through try ... finally and there is nothing after the cdtor_label. For arm there is RETURN_EXPR this; but we don't really care about the return value from ctors and dtors during the constexpr evaluation. I must say I don't see much the point of cdtor_labels at all, I'd think that with try ... finally around it for non-arm we could just RETURN_EXPR instead of the GOTO_EXPR and the try/finally gimplification would DTRT, and we could just add the right return value for the arm case. 2022-02-14 Jakub Jelinek PR c++/104513 * constexpr.cc (potential_constant_expression_1) : Don't punt if returns (target). * g++.dg/cpp1y/constexpr-104513.C: New test. * g++.dg/cpp2a/constexpr-dtor12.C: New test.
[Bug fortran/100337] Should be able to pass non-present optional arguments to CO_BROADCAST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100337 Andre Vehreschild changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andre Vehreschild --- Backported to gcc-11. Closing as fixed now.
[Bug target/104529] New: [missed optimization] inefficient codegen around new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
Bug ID: 104529
Summary: [missed optimization] inefficient codegen around
new/delete
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-*
Consider the following example
#include
#include
#include
struct param {
uint32_t k;
std::vector src;
std::vector ref0;
};
size_t foo() {
param test[] = {
{48, {255, 0, 0, 0, 0, 0}
}};
return sizeof(test);
}
where the entire thing should have been elided, but that is already reported in
#94294.
Instead this code also shows that we are generating quite inefficient code
(even at -Ofast)
on AArch64 we generate:
foo():
stp x29, x30, [sp, -32]!
mov w1, 255 <-- 1
mov x0, 6
mov x29, sp
str w1, [sp, 24] <-- 1
strhwzr, [sp, 28] <-- 2
bl operator new(unsigned long)
ldrhw3, [sp, 28] <-- 2
mov x1, 6
ldr w4, [sp, 24] <-- 1
str w4, [x0]
strhw3, [x0, 4]
bl operator delete(void*, unsigned long)
mov x0, 56
ldp x29, x30, [sp], 32
ret
There's no reason to spill and rematerialize a constant when the constant is
representable in a single move.
It's also unclear to me why it things the 255 and 0 need to be before the call
to new. But even if it did need it, it's better to re-create the constants
rather than materializing them again.
However x86 gets this right, which is why I've opened this as a target bug:
foo():
sub rsp, 8
mov edi, 6
calloperator new(unsigned long)
mov esi, 6
mov DWORD PTR [rax], 255
mov rdi, rax
xor eax, eax
mov WORD PTR [rdi+4], ax
calloperator delete(void*, unsigned long)
mov eax, 56
add rsp, 8
ret
[Bug fortran/100337] Should be able to pass non-present optional arguments to CO_BROADCAST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100337 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:ae57aae60d1be821feccb3160f8fdd5987ecba79 commit r11-9568-gae57aae60d1be821feccb3160f8fdd5987ecba79 Author: Andre Vehreschild Date: Mon Feb 14 16:47:16 2022 +0100 fortran: Fix deref of optional in gen. code. [PR100337, backport] gcc/fortran/ChangeLog: PR fortran/100337 Backport from master. * trans-intrinsic.c (conv_co_collective): Check stat for null ptr before dereferrencing. gcc/testsuite/ChangeLog: PR fortran/100337 * gfortran.dg/coarray_collectives_17.f90: New test.
[Bug middle-end/104522] ICE: in real_to_decimal_for_mode with -O -fdump-tree-all-details and long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522 --- Comment #9 from Jakub Jelinek --- Created attachment 52437 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52437&action=edit gcc12-pr104522.patch Patch I'll test tonight.
[Bug tree-optimization/94294] [missed optimization] new+delete of unused local string not removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94294
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comment #5 from Tamar Christina ---
(In reply to Marc Glisse from comment #4)
> I don't believe there is a "new/delete" issue.
I wonder.. , looking at
#include
#include
#include
struct param {
uint32_t k;
std::vector src;
std::vector ref0;
};
size_t foo() {
param test[] = {
{48, {255, 0, 0, 0, 0, 0}
}};
return sizeof(test);
}
I had expected the answer to simply be
mov w0, #56
ret
since the new and delete can be elided.
...but GCC generates some pretty bad code here...
https://godbolt.org/z/EPoYYohPa
In this case nothing of the structure is used at all yet we keep all the
construction code.
[Bug tree-optimization/104519] [12 Regression] wrong code at -Os on x86_64-linux-gnu and char as induction variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104519
--- Comment #7 from Richard Biener ---
Btw, to me it seems that since we are resolving condition 1) statically we know
that the difference of iv->base and final is positive with infinite
precision and fits the unsigned niter_type. To avoid going to the unsigned
type we can then indeed check multiple_of_p on each component, but we need
to use the original signedness here (or rather always signed?).
Using unsigned arithmetic for the
niter->niter = fold_build2 (EXACT_DIV_EXPR, niter_type, c, s);
in the end is consistent with the conditions we checked. So to preserve the
gist of Bins change I included it should probably read
diff --git a/gcc/tree-ssa-loop-niter.cc b/gcc/tree-ssa-loop-niter.cc
index 318d10c8fac..3ddc3a5c3a6 100644
--- a/gcc/tree-ssa-loop-niter.cc
+++ b/gcc/tree-ssa-loop-niter.cc
@@ -986,6 +986,7 @@ number_of_iterations_ne (class loop *loop, tree type,
affine_iv *iv,
bool exit_must_be_taken, bounds *bnds)
{
tree niter_type = unsigned_type_for (type);
+ tree stype = signed_type_for (niter_type);
tree s, c, d, bits, assumption, tmp, bound;
mpz_t max;
@@ -1051,10 +1052,10 @@ number_of_iterations_ne (class loop *loop, tree type,
affine_iv *iv,
along with condition 1) or 1'). */
if (!niter->control.no_overflow
&& (integer_onep (s)
- || (multiple_of_p (type, fold_convert (niter_type, iv->base), s,
-false)
- && multiple_of_p (type, fold_convert (niter_type, final), s,
- false
+ || (multiple_of_p (stype, fold_convert (stype, iv->base),
+fold_convert (stype, iv->step))
+ && multiple_of_p (stype, fold_convert (stype, final),
+ fold_convert (stype, iv->step)
{
tree t, cond, relaxed_cond = boolean_false_node;
[Bug fortran/103970] Multi-image co_broadcast of derived type with allocatable components fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103970 Andre Vehreschild changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andre Vehreschild --- Review was ok'ed and patch committed more than two weeks ago. Backport to gcc-11 committed as 680ee9c3332.
[Bug c++/103790] internal compiler error: Segmentation fault when playing with coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103790 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:680ee9c333280df74e06e1bc9f3be218424f94b3 commit r11-9567-g680ee9c333280df74e06e1bc9f3be218424f94b3 Author: Andre Vehreschild Date: Mon Feb 14 16:12:14 2022 +0100 Prevent malicious descriptor stacking for scalar components [V2, backport]. gcc/fortran/ChangeLog: PR fortran/103790 Backported from master. * trans-array.c (structure_alloc_comps): Prevent descriptor stacking for non-array data; do not broadcast caf-tokens. * trans-intrinsic.c (conv_co_collective): Prevent generation of unused descriptor. gcc/testsuite/ChangeLog: PR fortran/103790 * gfortran.dg/coarray_collectives_18.f90: New test.
[Bug tree-optimization/104519] [12 Regression] wrong code at -Os on x86_64-linux-gnu and char as induction variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104519
--- Comment #6 from Richard Biener ---
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 386d5732ea0..9d9939642f6 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -14208,11 +14208,7 @@ multiple_of_p (tree type, const_tree top, const_tree
bo
ttom, bool nowrap)
&& multiple_of_p (type, TREE_OPERAND (top, 2), bottom, nowrap));
case INTEGER_CST:
- if (TREE_CODE (bottom) != INTEGER_CST
- || integer_zerop (bottom)
- || (TYPE_UNSIGNED (type)
- && (tree_int_cst_sgn (top) < 0
- || tree_int_cst_sgn (bottom) < 0)))
+ if (TREE_CODE (bottom) != INTEGER_CST || integer_zerop (bottom))
return 0;
return wi::multiple_of_p (wi::to_widest (top), wi::to_widest (bottom),
SIGNED);
of course makes most sense there. I'm evaluating what
diff --git a/gcc/tree-ssa-loop-niter.cc b/gcc/tree-ssa-loop-niter.cc
index 318d10c8fac..2305e1d53f6 100644
--- a/gcc/tree-ssa-loop-niter.cc
+++ b/gcc/tree-ssa-loop-niter.cc
@@ -986,6 +986,7 @@ number_of_iterations_ne (class loop *loop, tree type,
affine_iv *iv,
bool exit_must_be_taken, bounds *bnds)
{
tree niter_type = unsigned_type_for (type);
+ tree stype = signed_type_for (niter_type);
tree s, c, d, bits, assumption, tmp, bound;
mpz_t max;
@@ -1051,10 +1052,8 @@ number_of_iterations_ne (class loop *loop, tree type,
affine_iv *iv,
along with condition 1) or 1'). */
if (!niter->control.no_overflow
&& (integer_onep (s)
- || (multiple_of_p (type, fold_convert (niter_type, iv->base), s,
-false)
- && multiple_of_p (type, fold_convert (niter_type, final), s,
- false
+ || multiple_of_p (stype, fold_convert (stype, c),
+ fold_convert (stype, iv->step
{
tree t, cond, relaxed_cond = boolean_false_node;
will yield since we are interpreting iv->step as signed. Pointers are
what makes this all a bit awkward since for those iv->base is a pointer
but iv->step is (unsigned) sizetype to be interpreted as signed.
Anyway, I do appreciate the extended test coverage we are getting from
the auto-generation of valid code people!
[Bug tree-optimization/104526] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104526
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
||amacleod at redhat dot com
Priority|P3 |P1
Last reconfirmed||2022-02-14
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Jakub Jelinek ---
Seems like something EVRP should optimize.
The pre- r12-6924 IL was:
c.0_1 = c;
_2 = *c.0_1;
# RANGE [-1, 1]
_3 = 1 / _2;
# RANGE [1, 2] NONZERO 3
d_11 = 2 >> _3;
and evrp properly figured out those ranges, that 1 / int is [-1, 1] and
that 2 >> [-1, 1] is [1, 2].
But since r12-6924 the IL is:
c.0_1 = c;
_2 = *c.0_1;
_11 = (unsigned int) _2;
_12 = _11 + 1;
_13 = _12 <= 2;
_3 = _12 <= 2 ? _2 : 0;
# RANGE [0, 2] NONZERO 3
d_14 = 2 >> _3;
and the range for d_14 is too broad (includes 0) and no ranges are recorded for
the other SSA_NAMEs.
Now, __1 and _12 are of course VARYING, and because _13 is _Bool, it is also
VARYING.
The important missing part is that we don't realize that _12 <= 2 ? _2 : 0
implies [-1, 1] range. The _2 + 1U <= 2U is a standard pattern how ranges are
encoded. Now if I rewrite the testcase by hand to:
void foo(void);
static int a, b = 1, *c = &b;
int main() {
for (; a; a--) {
int e;
int ct = *c;
if (ct + 1U <= 2U)
e = ct;
else
e = 0;
int d = 2 >> e;
if (!d)
foo();
}
}
which is equivalent to doing the 1 / int PR95424 optimization by hand, but
instead of having it in a COND_EXPR do it in separate bbs, i.e.:
c.0_1 = c;
ct_12 = *c.0_1;
ct.1_2 = (unsigned int) ct_12;
_3 = ct.1_2 + 1;
if (_3 <= 2)
goto ; [INV]
else
goto ; [INV]
:
:
# RANGE [-1, 1]
# e_7 = PHI
# RANGE [1, 2] NONZERO 3
d_15 = 2 >> e_7;
then evrp handles it just fine.
So, Andrew/Aldy, how hard would it be to improve ranger COND_EXPR handling, so
that it essentially does what we do for the PHI cases? I.e. from the COND_EXPR
condition, compute "assertion" if condition is true or if condition is false,
and use that on the COND_EXPR's second and third argument.
So for the
_3 = _12 <= 2 ? _2 : 0;
comparison, for second argument the condition must be true which implies that
_2 must be there [-1, 1], while for the third argument the condition must be
false, but the argument is constant 0, so range is [0, 0], then just union
those 2 ranges.
As this is a P1 regression, if we can fix it, would be nice to get it into GCC
12.
[Bug tree-optimization/104528] [12 Regression] ICE: Segmentation fault (in gimple_bb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104528 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug middle-end/104522] ICE: in real_to_decimal_for_mode with -O -fdump-tree-all-details and long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522 --- Comment #8 from Richard Biener --- So my question is whether something should normalize those numbers and why decode_ieee_extended happily initializes an invalid number (its documentation of course might suggest it only expects valid encoded numbers). But yes, enabling this re-interpretation checking unconditionally sounds like the way to go.
[Bug tree-optimization/102513] [10/11/12 Regression] Many false positive warnings with recursive function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513
--- Comment #8 from Martin Jambor ---
I am about to thest the following patch. In longer-run, it would be better to
never generate lattice values outside of the value_range but there is an
ordering problem, we need the complete VR info before we can use it. I plan to
rearrange IPA-CP into making multiple passes over the lattice dependency graph
and this should quite naturally be solved by doing this kind of
resursive-value-generation only in second and later passes.
diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index 453e9c93cc3..cbbb8bbc80a 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -6154,8 +6154,16 @@ decide_whether_version_node (struct cgraph_node *node)
{
ipcp_value *val;
for (val = lat->values; val; val = val->next)
- ret |= decide_about_value (node, i, -1, val, &avals,
- &self_gen_clones);
+ {
+ if (!plats->m_value_range.bottom_p ()
+ && !plats->m_value_range.m_vr.contains_p (val->value))
+ {
+ gcc_checking_assert (val->self_recursion_generated_p ());
+ continue;
+ }
+ ret |= decide_about_value (node, i, -1, val, &avals,
+&self_gen_clones);
+ }
}
if (!plats->aggs_bottom)
[Bug tree-optimization/104526] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104526 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r12-6924-gc2b610e7c6c89fd422c5c31f01023bcddf3cf4a5
[Bug tree-optimization/104528] [12 Regression] ICE: Segmentation fault (in gimple_bb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104528 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:0a1a3afb5fb36e2d10ad92bf788e16d837451571 commit r12-7228-g0a1a3afb5fb36e2d10ad92bf788e16d837451571 Author: Richard Biener Date: Mon Feb 14 13:37:54 2022 +0100 tree-optimization/104528 - free niter estimates after DSE When DSE removes a trivially dead def we have to reset niter information on loops since that might refer to it. The patch also adds verification to make sure this does not happen. 2022-02-14 Richard Biener PR tree-optimization/104528 * tree-ssa.h (find_released_ssa_name): Declare. * tree-ssa.cc (find_released_ssa_name): Export. * cfgloop.cc (verify_loop_structure): Look for released SSA names in loops nb_iterations. * tree-ssa-dse.cc (pass_dse::execute): Release number of iteration estimates. * gfortran.dg/pr104528.f: New testcase.
[Bug tree-optimization/104519] [12 Regression] wrong code at -Os on x86_64-linux-gnu and char as induction variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104519
Richard Biener changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #5 from Richard Biener ---
Hmm, for
b.2_2 = (unsigned char) b_lsm.6_13;
_3 = b.2_2 + 3;
_4 = (char) _3;
we analyze the evolution of _4 to {-4, +, 3}_1 (we're using an existing
upper bound for niter of 2). Eventually the bound we derive for this exit
causes us to disregard the other exit.
That upper bound of niter is from the main loop exit test at CD-DCE time.
Specifically multiple_of_p computes 249 % 3 is 0 and 0 % 3 is 0. It passes
wrong 'type', which doesn't end up mattering because the code seems
to look for mismatched type & type top/bottom(!?)
case INTEGER_CST:
if (TREE_CODE (bottom) != INTEGER_CST
|| integer_zerop (bottom)
|| (TYPE_UNSIGNED (type)
&& (tree_int_cst_sgn (top) < 0
|| tree_int_cst_sgn (bottom) < 0)))
return 0;
return wi::multiple_of_p (wi::to_widest (top), wi::to_widest (bottom),
SIGNED);
but then, we do
if (!niter->control.no_overflow
&& (integer_onep (s)
|| (multiple_of_p (niter_type, fold_convert (niter_type, iv->base),
s,
false)
&& multiple_of_p (niter_type, fold_convert (niter_type, final),
s,
false
so look for the multiple in unsigned arithmetic but then assume overflow
does not happen in signed arithmetic. That means the changes to
number_of_iterations_ne were wrong. Note the simplistic fix for
PR100499 regressed some testcases.
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 386d5732ea0..cdf34d81d90 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -14211,8 +14211,8 @@ multiple_of_p (tree type, const_tree top, const_tree
bottom, bool nowrap)
if (TREE_CODE (bottom) != INTEGER_CST
|| integer_zerop (bottom)
|| (TYPE_UNSIGNED (type)
- && (tree_int_cst_sgn (top) < 0
- || tree_int_cst_sgn (bottom) < 0)))
+ && (tree_int_cst_sign_bit (top)
+ || tree_int_cst_sign_bit (bottom
return 0;
return wi::multiple_of_p (wi::to_widest (top), wi::to_widest (bottom),
SIGNED);
diff --git a/gcc/tree-ssa-loop-niter.cc b/gcc/tree-ssa-loop-niter.cc
index 318d10c8fac..b8a628ea829 100644
--- a/gcc/tree-ssa-loop-niter.cc
+++ b/gcc/tree-ssa-loop-niter.cc
@@ -1051,9 +1051,9 @@ number_of_iterations_ne (class loop *loop, tree type,
affine_iv *iv,
along with condition 1) or 1'). */
if (!niter->control.no_overflow
&& (integer_onep (s)
- || (multiple_of_p (type, fold_convert (niter_type, iv->base), s,
+ || (multiple_of_p (niter_type, fold_convert (niter_type, iv->base),
s,
false)
- && multiple_of_p (type, fold_convert (niter_type, final), s,
+ && multiple_of_p (niter_type, fold_convert (niter_type, final),
s,
false
{
tree t, cond, relaxed_cond = boolean_false_node;
fixes this PR but I need to understand what multiple_of_p is doing here ...
[Bug middle-end/104522] ICE: in real_to_decimal_for_mode with -O -fdump-tree-all-details and long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522
--- Comment #7 from Jakub Jelinek ---
The MODE_COMPOSITE_P handling can be surely enabled for other modes too, I have
guarded it just because it slows compile time down a little bit and for usual
IEEE754 modes it should be always true, shouldn't it?
If i386/m68k XFmode is a problem too, we'd need some predicate how to find out
it is also problematic (the problem is the unnormals and other weird
representations in it, basically that not all bit patterns are valid).
native_decode_rtx has the same MODE_COMPOSITE_P handling:
rtx ret = native_decode_rtx (outermode, buffer, 0);
if (ret && MODE_COMPOSITE_P (outermode))
{
auto_vec buffer2 (buffer_bytes);
if (!native_encode_rtx (outermode, ret, buffer2, 0, buffer_bytes))
return NULL_RTX;
for (unsigned int i = 0; i < buffer_bytes; ++i)
if (buffer[i] != buffer2[i])
return NULL_RTX;
}
so again, it could be enabled for all scalar floating modes or composite and
the XF-ish modes.
[Bug libstdc++/103891] clang-13 fails to compile libstdc++'s std::variant>: error: attempt to use a deleted function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103891 --- Comment #9 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:164a761a9f4798dc69ecab80097807636dc17d61 commit r12-7227-g164a761a9f4798dc69ecab80097807636dc17d61 Author: Jonathan Wakely Date: Mon Feb 14 12:46:10 2022 + libstdc++: Use __cpp_concepts instead of custom macro [PR103891] With the new value of __cpp_concepts required by P2493, we can test whether the compiler supports conditionally trivial special members. This allows us to remove the workaround that disables fully-constexpr std::variant for Clang. Now it should work for non-GCC compilers (such as future releases of Clang) that support conditionally trivial destructors and define the new value of __cpp_concepts. libstdc++-v3/ChangeLog: PR libstdc++/103891 * include/bits/c++config (_GLIBCXX_HAVE_COND_TRIVIAL_SPECIAL_MEMBERS): Remove. * include/std/variant: Check feature test macros instead. * include/std/version: Likewise.
[Bug debug/104517] '-fcompare-debug' failure w/ -O1 -fopenmp -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104517 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-02-14 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #5 from Jakub Jelinek --- Created attachment 52436 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52436&action=edit gcc12-pr104517.patch Untested fix.
[Bug tree-optimization/104528] [12 Regression] ICE: Segmentation fault (in gimple_bb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104528 --- Comment #2 from Richard Biener --- At the start of IVOPTs we have (gdb) p debug_tree (cfun->x_current_loops->larray->m_vecdata[4]->nb_iterations) unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7670ce70 precision:32 min max > arg:0 nothrow def_stmt version:36 in-free-list> arg:1 arg:0 visited def_stmt pretmp_90 = ii; version:90>>> $12 = void so that mentions a released SSA name. It's released during DSE which fails to reset niter info since we now prune dead SSA names there.
[Bug tree-optimization/104528] [12 Regression] ICE: Segmentation fault (in gimple_bb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104528 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |12.0 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2022-02-14 --- Comment #1 from Richard Biener --- Usually a sign of using a stale SCEV cache entry.
[Bug c++/104514] add feature to create a pointer to a fixed address as constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104514 --- Comment #4 from Jonathan Wakely --- Yes, but this one asks for a new feature, not just "please make this kluge work again".
[Bug c++/104527] [11/12 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104527 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.3
[Bug middle-end/104522] ICE: in real_to_decimal_for_mode with -O -fdump-tree-all-details and long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Status|ASSIGNED|NEW Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug middle-end/104522] ICE: in real_to_decimal_for_mode with -O -fdump-tree-all-details and long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522
--- Comment #6 from Richard Biener ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Richard Biener from comment #4)
> > But I do wonder whether real_from_target needs fixing to handle invalid
> > input gracefully which is ultimatively decode_ieee_extended?
>
> long double foo (void)
> {
> union { int i[4]; long double ld; } __tmp
> = { .i = { 0x1, 0, 0x4000, 0 } };
> return __tmp.ld;
> }
>
> This will fail compilation (-O -dP), without -dP (which avoids printing),
> the constant in the memory is wrong:
>
> .LC0:
> .long 1
> .long 0
> .long 0 <--- here should be 16384
> .long 0
That's because encode_ieee_extended detects this (.uexp == 2) as denormal
and does
case rvc_normal:
{
int exp = REAL_EXP (r);
/* Recall that IEEE numbers are interpreted as 1.F x 2**exp,
whereas the intermediate representation is 0.F x 2**exp.
Which means we're off by one.
Except for Motorola, which consider exp=0 and explicit
integer bit set to continue to be normalized. In theory
this discrepancy has been taken care of by the difference
in fmt->emin in round_for_format. */
if (denormal)
exp = 0;
we do call round_for_format in advance but that does nothing here.
One question would be if native_interpret_real needs to call round_for_format
as well if that's the entity that's supposed to fixup "invalid" FP
encodings.
[Bug tree-optimization/104528] New: [12 Regression] ICE: Segmentation fault (in gimple_bb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104528 Bug ID: 104528 Summary: [12 Regression] ICE: Segmentation fault (in gimple_bb) 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: asolokha at gmx dot com Target Milestone: --- Created attachment 52435 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52435&action=edit Testcase gfortran 12.0.1 20220213 snapshot (g:58aeb75d4097010ad9bb72b964265b18ab284f93) ICEs when compiling the attached testcase w/ -O2 -fpeel-loops -ftree-loop-vectorize -fno-tree-scev-cprop --param iv-max-considered-uses=2: % gfortran-12.0.1 -O2 -fpeel-loops -ftree-loop-vectorize -fno-tree-scev-cprop --param iv-max-considered-uses=2 -c atm8wqik.f during GIMPLE pass: ivopts atm8wqik.f:1:37: 1 | REAL FUNCTION FOO(M, N, A, W) | ^ internal compiler error: Segmentation fault 0xf5175f crash_signal /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/toplev.cc:322 0x1e3964d gimple_bb /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/gimple.h:1871 0x1e3964d loop_containing_stmt /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-ssa-loop.h:76 0x1e3964d chrec_contains_symbols_defined_in_loop /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-chrec.cc:1009 0x1e39714 chrec_contains_symbols_defined_in_loop /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-chrec.cc:1026 0x1e397f4 chrec_contains_symbols_defined_in_loop(tree_node const*, unsigned int) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-chrec.cc:1039 0x10390e9 compute_overall_effect_of_inner_loop(loop*, tree_node*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:473 0x103963e follow_ssa_edge_inner_loop_phi /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1114 0x103963e follow_ssa_edge_expr /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1183 0x10397e0 follow_ssa_edge_in_condition_phi_branch /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1011 0x10397e0 follow_ssa_edge_in_condition_phi /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1037 0x10397e0 follow_ssa_edge_expr /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1165 0x10397e0 follow_ssa_edge_in_condition_phi_branch /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1011 0x10397e0 follow_ssa_edge_in_condition_phi /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1037 0x10397e0 follow_ssa_edge_expr /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1165 0x10397e0 follow_ssa_edge_in_condition_phi_branch /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1011 0x10397e0 follow_ssa_edge_in_condition_phi /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1037 0x10397e0 follow_ssa_edge_expr /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1165 0x10397e0 follow_ssa_edge_in_condition_phi_branch /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1011 0x10397e0 follow_ssa_edge_in_condition_phi /var/tmp/portage/sys-devel/gcc-12.0.1_p20220213/work/gcc-12-20220213/gcc/tree-scalar-evolution.cc:1037
[Bug c++/104507] [10/11 Regression] internal compiler error: unexpected expression ‘(int)(__ret)’ of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104507 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Yeah, I confirm it doesn't ICE starting with r12-4769-g9927ecbb42d5be48fa933adc26f8601fab5007ca and ICE started with r11-1449-gae2ebf011fec926e003645c33c07a03619ea216a which has been backported to 10 in r10-8315-g1bab254fd30c2b94a675b9057349fc80946375b1
[Bug c/104506] [12 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:87 on invalid symbol redeclaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104506 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||sayle at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Confirmed it is r12-3278-g823685221de98
[Bug middle-end/104522] ICE: in real_to_decimal_for_mode with -O -fdump-tree-all-details and long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104522
--- Comment #5 from Uroš Bizjak ---
(In reply to Richard Biener from comment #4)
> But I do wonder whether real_from_target needs fixing to handle invalid
> input gracefully which is ultimatively decode_ieee_extended?
long double foo (void)
{
union { int i[4]; long double ld; } __tmp
= { .i = { 0x1, 0, 0x4000, 0 } };
return __tmp.ld;
}
This will fail compilation (-O -dP), without -dP (which avoids printing), the
constant in the memory is wrong:
.LC0:
.long 1
.long 0
.long 0 <--- here should be 16384
.long 0
[Bug target/104525] timeout on signed overflow at O0 fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104525 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- And on -fsigned-char targets, -fwrapv isn't needed, there isn't signed integer overflow, because c -= 3 promotes to int, so it is actually c = (signed char) ((int) c - 3)
