[Bug ipa/103486] New: ICE on valid code at -Os and above on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103486
Bug ID: 103486
Summary: ICE on valid code at -Os and above on
x86_64-linux-gnu: Segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
Target Milestone: ---
It seems to be a recent regression.
[536] % 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.0/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.0 20211130 (experimental) [master r12-5591-g2acbc4eba33] (GCC)
[537] %
[537] % gcctk -O1 small.c; ./a.out
[538] %
[538] % gcctk -Os small.c
during IPA pass: inline
small.c:10:1: internal compiler error: Segmentation fault
10 | }
| ^
0xe9256f crash_signal
../../gcc-trunk/gcc/toplev.c:322
0x1c9e436 operator_div::wi_fold(irange&, tree_node*,
generic_wide_int const&, generic_wide_int
const&, generic_wide_int const&,
generic_wide_int const&) const
../../gcc-trunk/gcc/range-op.cc:1836
0x1c9ac4f range_operator::wi_fold_in_parts(irange&, tree_node*,
generic_wide_int const&, generic_wide_int
const&, generic_wide_int const&,
generic_wide_int const&) const
../../gcc-trunk/gcc/range-op.cc:192
0x1c9b4af range_operator::fold_range(irange&, tree_node*, irange const&, irange
const&, tree_code) const
../../gcc-trunk/gcc/range-op.cc:214
0x11b2a54 range_fold_binary_expr(int_range<1u>*, tree_code, tree_node*,
int_range<1u> const*, int_range<1u> const*)
../../gcc-trunk/gcc/tree-vrp.c:1080
0xbcc942 evaluate_conditions_for_known_args
../../gcc-trunk/gcc/ipa-fnsummary.c:511
0xbd1fae evaluate_properties_for_edge(cgraph_edge*, bool, unsigned int*,
unsigned int*, ipa_auto_call_arg_values*, bool)
../../gcc-trunk/gcc/ipa-fnsummary.c:726
0xbe83ed do_estimate_edge_size(cgraph_edge*)
../../gcc-trunk/gcc/ipa-inline-analysis.c:330
0xbeaa0f estimate_edge_size
../../gcc-trunk/gcc/ipa-inline.h:79
0xbeaa0f estimate_edge_growth
../../gcc-trunk/gcc/ipa-inline.h:100
0xbeaa0f do_estimate_growth_1
../../gcc-trunk/gcc/ipa-inline-analysis.c:429
0xbeaf55 cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
../../gcc-trunk/gcc/cgraph.h:3411
0xbeaf55 estimate_growth(cgraph_node*)
../../gcc-trunk/gcc/ipa-inline-analysis.c:467
0x1c09543 inline_small_functions
../../gcc-trunk/gcc/ipa-inline.c:1980
0x1c09543 ipa_inline
../../gcc-trunk/gcc/ipa-inline.c:2743
0x1c09543 execute
../../gcc-trunk/gcc/ipa-inline.c:3142
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[539] %
[539] % cat small.c
int a, b;
void c(long d) {
while (1)
a = a && (1 / d);
}
int main() {
if (a)
c(b);
return 0;
}
[Bug c++/86329] Bogus fix-it hint: note: suggested alternative: '._72'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86329
Eric Gallager changed:
What|Removed |Added
Resolution|--- |FIXED
CC||egallager at gcc dot gnu.org
Status|ASSIGNED|RESOLVED
--- Comment #8 from Eric Gallager ---
(In reply to Eric Gallager from comment #7)
> (In reply to Eric Gallager from comment #5)
> > (In reply to David Malcolm from comment #4)
> > > Fixed on trunk by r262199; still affects gcc-8 and gcc-7 branches.
> >
> > so what should be the target milestone then?
>
> (In reply to David Malcolm from comment #6)
> > Author: dmalcolm
> > Date: Thu Feb 14 23:02:45 2019
> > New Revision: 268909
> >
> > URL: https://gcc.gnu.org/viewcvs?rev=268909&root=gcc&view=rev
> > Log:
> > C++: don't offer bogus "._0" suggestions (PR c++/86329)
> >
> > PR c++/86329 reports that the C++ frontend can offer bogus suggestions like:
> >
> > #include
> >
> > int compare()
> > {
> > return __n1 - __n2;
> > }
> >
> > suggested.cc: In function 'int compare()':
> > suggested.cc:5:10: error: '__n1' was not declared in this scope
> >return __n1 - __n2;
> > ^~~~
> > suggested.cc:5:10: note: suggested alternative: '._61'
> >return __n1 - __n2;
> > ^~~~
> > ._61
> > suggested.cc:5:17: error: '__n2' was not declared in this scope
> >return __n1 - __n2;
> > ^~~~
> > suggested.cc:5:17: note: suggested alternative: '._72'
> >return __n1 - __n2;
> > ^~~~
> > ._72
> >
> > The dot-prefixed names are an implementation detail of how we implement
> > anonymous enums found in the header files, generated via
> > anon_aggrname_format in make_anon_name.
> >
> > This patch uses anon_aggrname_p to filter them out when considering
> > which names to suggest.
> >
> > gcc/cp/ChangeLog:
> > Backport of r262199 from trunk.
> > 2018-06-27 David Malcolm
> >
> > PR c++/86329
> > * name-lookup.c (consider_binding_level): Filter out names that
> > match anon_aggrname_p.
> >
> > gcc/testsuite/ChangeLog:
> > Backport of r262199 from trunk.
> > 2018-06-27 David Malcolm
> >
> > PR c++/86329
> > * g++.dg/lookup/pr86329.C: New test.
> >
> >
> > Added:
> > branches/gcc-8-branch/gcc/testsuite/g++.dg/lookup/pr86329.C
> > Modified:
> > branches/gcc-8-branch/gcc/cp/ChangeLog
> > branches/gcc-8-branch/gcc/cp/name-lookup.c
> > branches/gcc-8-branch/gcc/testsuite/ChangeLog
>
> So, since this fixed it for 8, just 7 is left, so changing the target
> milestone to 7.4
I'm pretty sure 7 is closed now, so I'm going to close this as fixed for open
branches.
[Bug target/87243] FSF GCC needs to do something special (like using xcrun) on darwin18 to find system headers in SDK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||fink at snaggledworks dot com, ||ken.cunningham.webuse@gmail ||.com --- Comment #15 from Eric Gallager --- (In reply to Eric Gallager from comment #14) > Related downstream issue from MacPorts: > https://trac.macports.org/ticket/59113 (that's fixed now, btw... ok to close this now as well?)
[Bug c/92479] missing warnings for unreachable codes with break (i.e. revive the subset of -Wunreachable-code that fits under clang's -Wunreachable-code-break)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479
--- Comment #11 from rguenther at suse dot de ---
On Tue, 30 Nov 2021, egallager at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479
>
> --- Comment #10 from Eric Gallager ---
> (In reply to Richard Biener from comment #9)
> > I'm going to re-interpret -Wunreachable-code-{return,break} to mean to
> > diagnose unreachable code _after_ a return stmt or a break stmt. It really
> > looks like clang went out with a hammer, assigning a different option to
> > each diagnostic invocation with a different text ...
>
> I actually appreciate that about clang; additional warning flag granularity
> helps to break warning-silencing tasks down in to more-easily manageable parts
> when there are a lot of similar warnings. Sometimes I might want to only focus
> on one while saving the other for later.
I see. Just in this case the choice to differentiate seems silly.
[Bug rtl-optimization/103485] [12 Regression] ICE: in emit_move_insn, at expr.c:4013 with -O -fno-tree-dce -fno-tree-dse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103485 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e2521cd2d26661cfcfceaabf9bd281ef316fd3fc commit r12-5593-ge2521cd2d26661cfcfceaabf9bd281ef316fd3fc Author: Richard Biener Date: Tue Nov 30 08:19:24 2021 +0100 middle-end/103485 - fix conversion kind for vectors This makes sure to use a VIEW_CONVERT_EXPR for converting vector signedness in the -((int)x >> (prec - 1)) to (unsigned)x >> (prec - 1) simplification. 2021-11-30 Richard Biener PR middle-end/103485 * match.pd (-((int)x >> (prec - 1)) to (unsigned)x >> (prec - 1)): Use VIEW_CONVERT_EXPR for vectors. * gcc.dg/pr103485.c: New testcase.
[Bug rtl-optimization/103485] [12 Regression] ICE: in emit_move_insn, at expr.c:4013 with -O -fno-tree-dce -fno-tree-dse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103485 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Richard Biener --- Fixed.
[Bug target/87243] FSF GCC needs to do something special (like using xcrun) on darwin18 to find system headers in SDK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Iain Sandoe --- fixed on open branches (As described in the various comments, I do not intend to spawn xcrun from the compiler - neither does clang).
[Bug target/103463] [12 Regression] ICE: in ix86_attr_length_immediate_default, at config/i386/i386.c:16686 with -Os -fno-tree-dominator-opts -fno-tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103463
--- Comment #5 from Hongtao.liu ---
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index c88374c9d2b..4e9fae80479 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -11512,6 +11512,7 @@ (define_insn "*x86_64_shld_1"
[(set_attr "type" "ishift")
(set_attr "prefix_0f" "1")
(set_attr "mode" "DI")
+ (set_attr "length_immediate" "1")
(set_attr "athlon_decode" "vector")
(set_attr "amdfam10_decode" "vector")
(set_attr "bdver1_decode" "vector")])
@@ -11573,6 +11574,7 @@ (define_insn "*x86_shld_1"
"shld{l}\t{%2, %1, %0|%0, %1, %2}"
[(set_attr "type" "ishift")
(set_attr "prefix_0f" "1")
+ (set_attr "length_immediate" "1")
(set_attr "mode" "SI")
(set_attr "pent_pair" "np")
(set_attr "athlon_decode" "vector")
@@ -12384,6 +12386,7 @@ (define_insn "*x86_64_shrd_1"
"shrd{q}\t{%2, %1, %0|%0, %1, %2}"
[(set_attr "type" "ishift")
(set_attr "prefix_0f" "1")
+ (set_attr "length_immediate" "1")
(set_attr "mode" "DI")
(set_attr "athlon_decode" "vector")
(set_attr "amdfam10_decode" "vector")
@@ -12446,6 +12449,7 @@ (define_insn "*x86_shrd_1"
"shrd{l}\t{%2, %1, %0|%0, %1, %2}"
[(set_attr "type" "ishift")
(set_attr "prefix_0f" "1")
+ (set_attr "length_immediate" "1")
(set_attr "mode" "SI")
(set_attr "pent_pair" "np")
(set_attr "athlon_decode" "vector")
[Bug ipa/103486] ICE on valid code at -Os and above on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103486 Richard Biener changed: What|Removed |Added Version|unknown |12.0 --- Comment #1 from Richard Biener --- Seems to be yet another duplicate.
[Bug target/103484] [12 Regression] ICE: in ix86_attr_length_immediate_default, at config/i386/i386.c:16686 with -O2 -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103484 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #1 from Hongtao.liu --- (In reply to Zdenek Sojka from comment #0) > Created attachment 51904 [details] > reduced testcase > > This happens even after the PR103463 fix. > PR103463 is not fixed, it just happen not to generate the problematic insn. I've root caused the issue, and testing a patch.
[Bug target/100711] Miss optimization for pandn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711 --- Comment #6 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:c39d77f252e895306ef88c1efb3eff04e4232554 commit r12-5595-gc39d77f252e895306ef88c1efb3eff04e4232554 Author: Roger Sayle Date: Tue Nov 30 08:35:39 2021 + x86_64: PR target/100711: Splitters for pandn This patch addresses PR target/100711 by introducing define_split patterns so that not/broadcast/pand may be simplified (by combine) to broadcast/pandn. This introduces two splitters one for optimizing pandn on TARGET_SSE for V4SI and V2DI, and another for vpandn on TARGET_AVX2 for V16QI, V8HI, V32QI, V16HI and V8SI. Each splitter has its own new testcase. I've also confirmed that not/broadcast/pandn is already getting simplified to broadcast/pand by the middle-end optimizers. 2021-11-30 Roger Sayle Uroš Bizjak gcc/ChangeLog PR target/100711 * config/i386/sse.md (define_split): New splitters to simplify not;vec_duplicate;and as vec_duplicate;andn. gcc/testsuite/ChangeLog PR target/100711 * gcc.target/i386/pr100711-1.c: New test case. * gcc.target/i386/pr100711-2.c: New test case.
[Bug target/100711] Miss optimization for pandn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711 Hongtao.liu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Hongtao.liu --- Fixed in GCC12.
[Bug c++/100977] [C++23] Implement C++ Identifier Syntax using Unicode Standard Annex 31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100977
--- Comment #14 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7abcc9ca20d4e17deabb308b5f483aaccc3dc02c
commit r12-5597-g7abcc9ca20d4e17deabb308b5f483aaccc3dc02c
Author: Jakub Jelinek
Date: Tue Nov 30 09:50:52 2021 +0100
libcpp: Enable P1949R7 for C++11 and up as it was a DR [PR100977]
Jonathan mentioned on IRC that:
"Accept P1949R7 (C++ Identifier Syntax using Unicode Standard Annex 31) as
a Defect Report and apply the changes therein to the C++ working paper."
while I've actually implemented it only for -std={gnu,c}++{23,2b}.
As the C++98 rules were significantly different, I'm not trying to change
anything for C++98.
2021-11-30 Jakub Jelinek
PR c++/100977
* init.c (lang_defaults): Enable cxx23_identifiers for
-std={gnu,c}++{11,14,17,20} too.
* c-c++-common/cpp/ucnid-2011-1-utf8.c: Expect errors in C++.
* c-c++-common/cpp/ucnid-2011-1.c: Likewise.
* g++.dg/cpp/ucnid-4-utf8.C: Add missing space to dg-options.
* g++.dg/cpp23/normalize3.C: Enable for c++11 rather than just
c++23.
* g++.dg/cpp23/normalize4.C: Likewise.
* g++.dg/cpp23/normalize5.C: Likewise.
* g++.dg/cpp23/normalize7.C: Expect errors rather than just
warnings
for c++11 and up rather than just c++23.
* g++.dg/cpp23/ucnid-2-utf8.C: Expect errors even for c++11 ..
c++20.
[Bug ipa/103486] ICE on valid code at -Os and above on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103486 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Aldy Hernandez --- duplicate. fixed with my proposed patch. *** This bug has been marked as a duplicate of bug 103451 ***
[Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451 Aldy Hernandez changed: What|Removed |Added CC||zhendong.su at inf dot ethz.ch --- Comment #7 from Aldy Hernandez --- *** Bug 103486 has been marked as a duplicate of this bug. ***
[Bug other/103487] New: "paranoia" Makefile target in gcc/Makefile fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103487
Bug ID: 103487
Summary: "paranoia" Makefile target in gcc/Makefile fails to
build
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: egallager at gcc dot gnu.org
CC: rth at gcc dot gnu.org
Target Milestone: ---
Looks like contrib/paranoia.cc hasn't been updated in a while:
g++ -c -g -DIN_GCC -fPIC -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common
-DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I../../gcc/../libcpp/include -I../../gcc/../libcody -I/opt/local/include
-I/opt/local/include -I/opt/local/include -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace
-I/opt/local/include ../../gcc/../contrib/paranoia.cc -o paranoia.o
In file included from ../../gcc/../contrib/paranoia.cc:154:
../../gcc/hwint.h:291:7: error: use of undeclared identifier
'gcc_checking_assert'
gcc_checking_assert (prec < HOST_BITS_PER_WIDE_INT);
^
../../gcc/hwint.h:314:7: error: use of undeclared identifier
'gcc_checking_assert'
gcc_checking_assert (prec < HOST_BITS_PER_WIDE_INT);
^
../../gcc/hwint.h:324:3: error: use of undeclared identifier
'gcc_checking_assert'
gcc_checking_assert (x != HOST_WIDE_INT_MIN);
^
../../gcc/hwint.h:361:1: error: conflicting types for 'mul_hwi'
mul_hwi (HOST_WIDE_INT a, HOST_WIDE_INT b, bool *overflow)
^
../../gcc/hwint.h:264:22: note: previous declaration is here
extern HOST_WIDE_INT mul_hwi (HOST_WIDE_INT, HOST_WIDE_INT);
^
../../gcc/../contrib/paranoia.cc:172:9: warning: keyword is hidden by macro
definition [-Wkeyword-macro]
#define class klass
^
In file included from ../../gcc/../contrib/paranoia.cc:174:
../../gcc/real.h:181:24: error: use of undeclared identifier 'NUM_MODE_FLOAT'
real_format_for_mode[NUM_MODE_FLOAT + NUM_MODE_DECIMAL_FLOAT];
^
../../gcc/real.h:181:41: error: use of undeclared identifier
'NUM_MODE_DECIMAL_FLOAT'
real_format_for_mode[NUM_MODE_FLOAT + NUM_MODE_DECIMAL_FLOAT];
^
../../gcc/real.h:216:1: error: unknown type name 'klass'; did you mean 'class'?
class format_helper
^
class
../../gcc/../contrib/paranoia.cc:172:15: note: expanded from macro 'class'
#define class klass
^
In file included from ../../gcc/../contrib/paranoia.cc:174:
../../gcc/real.h:220:3: error: templates must have C++ linkage
template format_helper (const T &);
^~~~
../../gcc/../contrib/paranoia.cc:135:3: note: extern "C" language linkage
specification begins here
extern "C" {
^
In file included from ../../gcc/../contrib/paranoia.cc:174:
../../gcc/real.h:231:1: error: templates must have C++ linkage
template
^~~~
../../gcc/../contrib/paranoia.cc:135:3: note: extern "C" language linkage
specification begins here
extern "C" {
^
In file included from ../../gcc/../contrib/paranoia.cc:174:
../../gcc/real.h:233:35: error: use of undeclared identifier 'gcc_unreachable'
: m_format (m == VOIDmode ? 0 : REAL_MODE_FORMAT (m))
^
../../gcc/real.h:189:7: note: expanded from macro 'REAL_MODE_FORMAT'
: (gcc_unreachable (), 0)])
^
../../gcc/real.h:233:35: error: use of undeclared identifier
'MIN_MODE_DECIMAL_FLOAT'
../../gcc/real.h:185:17: note: expanded from macro 'REAL_MODE_FORMAT'
? (((MODE) - MIN_MODE_DECIMAL_FLOAT)\
^
../../gcc/real.h:233:35: error: use of undeclared identifier 'NUM_MODE_FLOAT'
../../gcc/real.h:186:9: note: expanded from macro 'REAL_MODE_FORMAT'
+ NUM_MODE_FLOAT)\
^
../../gcc/real.h:233:35: error: use of undeclared identifier 'MODE_FLOAT'
../../gcc/real.h:187:31: note: expanded from macro 'REAL_MODE_FORMAT'
: GET_MODE_CLASS (MODE) == MODE_FLOAT \
^
../../gcc/real.h:233:35: error: use of undeclared identifier 'MIN_MODE_FLOAT'
../../gcc/real.h:188:16: note: expanded from macro 'REAL_MODE_FORMAT'
? ((MODE) - MIN_MODE_FLOAT) \
^
../../gcc/real.h:233:20: error: use of undeclared identifier 'VOIDmode'
: m_format (m == VOIDmode ? 0 : REAL_MODE_FORMAT (m))
^
../../gcc/real.h:243:25: error: unknown type name '
[Bug preprocessor/103488] New: cpp --help lists some options that are silently ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103488
Bug ID: 103488
Summary: cpp --help lists some options that are silently
ignored
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: adl at gnu dot org
Target Milestone: ---
Hi!
Sorry for this trivialish issue, but that puzzled me for 10 minutes this
morning while I was looking whether cpp had some option I needed.
The help text of cpp suggests that `cpp --help=common' will work, but that
option seems to be silently ignored.
% cpp --version | sed 1q
cpp (Debian 11.2.0-12) 11.2.0
% cpp --help | sed 7q
Usage: cpp [options] file...
Options:
-pass-exit-codes Exit with highest error code from a phase.
--help Display this information.
--target-helpDisplay target specific command line options.
--help={common|optimizers|params|target|warnings|[^]{joined|separate|undocumented}}[,...].
Display specific types of command line options.
% cpp --help=common "
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 ""
% cpp --help=foobarbaz "
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 ""
Given this help text, I would have expected any use of --help=... to prevent
the normal behavior of cpp, and I would have expected a diagnostic for
--help=foobarbaz.
[Bug target/103274] [10/11/12 regression] remaining -freorder-blocks-and-partition/ glitch with Windows SEH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274 --- Comment #7 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:bc8d6c60137f8bbf173b86ddf31b15d7ba2a33dd commit r12-5598-gbc8d6c60137f8bbf173b86ddf31b15d7ba2a33dd Author: Eric Botcazou Date: Tue Nov 30 10:17:09 2021 +0100 Fix -freorder-blocks-and-partition glitch with Windows SEH (continued) This fixes a thinko in the fix for the -freorder-blocks-and-partition glitch with SEH on 64-bit Windows: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565208.html Even if no exceptions are active, e.g. in C, we need to consider calls. gcc/ PR target/103274 * config/i386/i386.c (ix86_output_call_insn): Beef up comment about nops emitted with SEH. * config/i386/winnt.c (i386_pe_seh_unwind_emit): When switching to the cold section, emit a nop before the directive if the previous active instruction is a call.
[Bug tree-optimization/103489] New: ICE with -O3 in operator[], at vec.h:889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103489
Bug ID: 103489
Summary: ICE with -O3 in operator[], at vec.h:889
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskij at frtk dot ru
Target Milestone: ---
The same reproducer also triggers ICE for Sapphire Rapids with a different
stack trace.
Link to the Compiler Explorer: https://godbolt.org/z/nxqPhnnoe
Reproducer:
bool a[80];
short b, f;
void g(short h[][8][16]) {
for (bool c = 0; c < b;)
for (bool d = 0; d < (bool)f; d = 1)
for (short e = 0; e < 16; e++)
a[e] = h[b][1][e];
}
Error:
>$ g++ -O3 -c func.cpp
during GIMPLE pass: slp
func.cpp: In function 'void g(short int (*)[8][16])':
func.cpp:3:6: internal compiler error: in operator[], at vec.h:889
3 | void g(short h[][8][16]) {
| ^
0x8b7e0a vec::operator[](unsigned int)
/testing/gcc/gcc_src_master/gcc/vec.h:889
0x8b896f vec::operator[](unsigned int)
/testing/gcc/gcc_src_master/gcc/tree-vect-loop.c:7877
0x8b896f vec::operator[](unsigned int)
/testing/gcc/gcc_src_master/gcc/vec.h:1495
0x8b896f vectorizable_phi(vec_info*, _stmt_vec_info*, gimple**, _slp_tree*,
vec*)
/testing/gcc/gcc_src_master/gcc/tree-vect-loop.c:7869
0x2093485 vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
/testing/gcc/gcc_src_master/gcc/tree-vect-stmts.c:11174
0x1485797 vect_schedule_slp_node
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.c:7252
0x1496756 vect_schedule_scc
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.c:7450
0x14964e9 vect_schedule_scc
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.c:7431
0x14964e9 vect_schedule_scc
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.c:7431
0x1496daf vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.c:7567
0x1498573 vect_slp_region
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.c:5926
0x1499503 vect_slp_bbs
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.c:6038
0x14998fc vect_slp_function(function*)
/testing/gcc/gcc_src_master/gcc/tree-vect-slp.c:6126
0x14a02f2 execute
/testing/gcc/gcc_src_master/gcc/tree-vectorizer.c:1503
Sapphire Rapids Error:
>$ g++ -O3 -c func.cpp -march=sapphirerapids
func.cpp: In function 'void g(short int (*)[8][16])':
func.cpp:3:6: error: incompatible types in 'PHI' argument 1
3 | void g(short h[][8][16]) {
| ^
vector(16) unsigned char
vector(16)
vect_a_I_lsm.30_92 = PHI <_97(2), mask__28.29_93(4)>
during GIMPLE pass: slp
func.cpp:3:6: internal compiler error: verify_gimple failed
0x123e31a verify_gimple_in_cfg(function*, bool)
/testing/gcc/gcc_src_master/gcc/tree-cfg.c:5578
0x110638f execute_function_todo
/testing/gcc/gcc_src_master/gcc/passes.c:2084
0x110693b execute_todo
/testing/gcc/gcc_src_master/gcc/passes.c:2138
gcc version 12.0.0 20211129 (ca5667e867252db3c8642ee90f55427149cd92b6) (GCC)
[Bug target/103274] [10/11/12 regression] remaining -freorder-blocks-and-partition/ glitch with Windows SEH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:aef7d09baf91341540e7d468419918d58dd33601 commit r11-9343-gaef7d09baf91341540e7d468419918d58dd33601 Author: Eric Botcazou Date: Tue Nov 30 10:17:09 2021 +0100 Fix -freorder-blocks-and-partition glitch with Windows SEH (continued) This fixes a thinko in the fix for the -freorder-blocks-and-partition glitch with SEH on 64-bit Windows: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565208.html Even if no exceptions are active, e.g. in C, we need to consider calls. gcc/ PR target/103274 * config/i386/i386.c (ix86_output_call_insn): Beef up comment about nops emitted with SEH. * config/i386/winnt.c (i386_pe_seh_unwind_emit): When switching to the cold section, emit a nop before the directive if the previous active instruction is a call.
[Bug target/103274] [10/11/12 regression] remaining -freorder-blocks-and-partition/ glitch with Windows SEH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:ecc34ba16920957de21f89fc8b4c9efef7786f72 commit r10-10316-gecc34ba16920957de21f89fc8b4c9efef7786f72 Author: Eric Botcazou Date: Tue Nov 30 10:17:09 2021 +0100 Fix -freorder-blocks-and-partition glitch with Windows SEH (continued) This fixes a thinko in the fix for the -freorder-blocks-and-partition glitch with SEH on 64-bit Windows: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565208.html Even if no exceptions are active, e.g. in C, we need to consider calls. gcc/ PR target/103274 * config/i386/i386.c (ix86_output_call_insn): Beef up comment about nops emitted with SEH. * config/i386/winnt.c (i386_pe_seh_unwind_emit): When switching to the cold section, emit a nop before the directive if the previous active instruction is a call.
[Bug target/103274] [10/11/12 regression] remaining -freorder-blocks-and-partition/ glitch with Windows SEH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Eric Botcazou --- Thanks for reporting the problem.
[Bug c++/103490] New: Linkage type of typeinfo of polymorphic object with OOL functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103490
Bug ID: 103490
Summary: Linkage type of typeinfo of polymorphic object with
OOL functions
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lizekun.zek at bytedance dot com
Target Milestone: ---
Hi guys,
I found that the linkage of typeinfo of polymorphic object with OOL-functions
is weak, while that is strong for clang, and I want to attach a patch to make
the behavior of the two compilers consistent. However, I can't find the clear
definition of this in Itanium C++ ABI, so here are the questions:
1.It is easy to understand that we make the object with inlined-functions weak,
because it usually appears in a header file and may be defined several times,
so when functions are out-of-line, why do we make it weak?
2.In fact, I prefer the gcc way, are there any cases that show gcc is
better?
This is a case to show the issue.
---
test.h
class A{
public:
virtual const int getA(){} ;
virtual const int getB(){} ;
};
---
testA.cpp
#include
#include "test.h"
using namespace std;
class Test : public A {
public:
virtual const int getA() override;
};
const int Test ::getA() {
return 1;
}
int main() {
A * t=new Test();;
cout << dynamic_cast(t);
}
---
testB.cpp
#include "test.h"
class Test : A {
public:
virtual const int getB() override;
};
const int Test :: getB() {
return 2;
}
[Bug testsuite/103477] [12 regression] gcc.dg/tree-ssa/pr103345.c fails after r12-5453
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103477 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com Last reconfirmed||2021-11-30 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com --- Comment #2 from Roger Sayle --- Doh! There's a typo/mistake in the new testcase. I'll push a fix shortly. Sorry for the inconvenience.
[Bug tree-optimization/102467] Missed SLP discovery for gathers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102467 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:10833849b55401a52f2334eb032a70beb688e9fc commit r12-5612-g10833849b55401a52f2334eb032a70beb688e9fc Author: Richard Sandiford Date: Tue Nov 30 09:52:29 2021 + vect: Support gather loads with SLP This patch adds SLP support for IFN_GATHER_LOAD. Like the SLP support for IFN_MASK_LOAD, it works by treating only some of the arguments as child nodes. Unlike IFN_MASK_LOAD, it requires the other arguments (base, scale, and extension type) to be the same for all calls in the group. It does not require/expect the loads to be in a group (which probably wouldn't make sense for gathers). I was worried about the possible alias effect of moving gathers around to be part of the same SLP group. The patch therefore makes vect_analyze_data_ref_dependence treat gathers and scatters as a top-level concern, punting if the accesses aren't completely independent and if the user hasn't told us that a particular VF is safe. I think in practice we already punted in the same circumstances; the idea is just to make it more explicit. gcc/ PR tree-optimization/102467 * doc/sourcebuild.texi (vect_gather_load_ifn): Document. * tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Commonize safelen handling. Punt for anything involving gathers and scatters unless safelen says otherwise. * tree-vect-slp.c (arg1_map): New variable. (vect_get_operand_map): Handle IFN_GATHER_LOAD. (vect_build_slp_tree_1): Likewise. (vect_build_slp_tree_2): Likewise. (compatible_calls_p): If vect_get_operand_map returns nonnull, check that any skipped arguments are equal. (vect_slp_analyze_node_operations_1): Tighten reduction check. * tree-vect-stmts.c (check_load_store_for_partial_vectors): Take an ncopies argument. (vect_get_gather_scatter_ops): Take slp_node and ncopies arguments. Handle SLP nodes. (vectorizable_store, vectorizable_load): Adjust accordingly. gcc/testsuite/ * lib/target-supports.exp (check_effective_target_vect_gather_load_ifn): New target test. * gcc.dg/vect/vect-gather-1.c: New test. * gcc.dg/vect/vect-gather-2.c: Likewise. * gcc.target/aarch64/sve/gather_load_11.c: Likewise.
[Bug testsuite/101751] asan_test.C fails with excess error with glibc-2.34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101751 --- Comment #3 from Florian Weimer --- Patch posted: [PATCH] Avoid expecting nonzero size for access none void* arguments [PR101751] https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585377.html
[Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451 --- Comment #8 from CVS Commits --- The trunk branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:f33fdda0b805ff6097f9f325d73a4b07e72170b0 commit r12-5615-gf33fdda0b805ff6097f9f325d73a4b07e72170b0 Author: Aldy Hernandez Date: Mon Nov 29 12:52:45 2021 +0100 Remove can_throw_non_call_exceptions special case from operator_div::wi_fold. PR tree-optimization/103451 gcc/ChangeLog: * range-op.cc (operator_div::wi_fold): Remove can_throw_non_call_exceptions special case. * tree-ssa-sink.c (sink_code_in_bb): Same. gcc/testsuite/ChangeLog: * gcc.dg/pr103451.c: New test.
[Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Aldy Hernandez --- fixed
[Bug testsuite/103477] [12 regression] gcc.dg/tree-ssa/pr103345.c fails after r12-5453
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103477 --- Comment #3 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:92de188ea3d36ec012b6d42959d4722e42524256 commit r12-5616-g92de188ea3d36ec012b6d42959d4722e42524256 Author: Roger Sayle Date: Tue Nov 30 10:25:35 2021 + [Committed] PR testsuite/103477: Fix big-endian mistake in new test case. I missed a spot when adding the "#if __BYTE_ORDER__ == ..." guards to the new test case for PR tree-optimization/103345. Committed as obvious. 2021-11-30 Roger Sayle gcc/testsuite/ChangeLog PR testsuite/103477 * gcc.dg/tree-ssa/pr103345.c: Correct xor test for big-endian.
[Bug tree-optimization/103345] missed optimization: add/xor individual bytes to form a word
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103345 --- Comment #6 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:92de188ea3d36ec012b6d42959d4722e42524256 commit r12-5616-g92de188ea3d36ec012b6d42959d4722e42524256 Author: Roger Sayle Date: Tue Nov 30 10:25:35 2021 + [Committed] PR testsuite/103477: Fix big-endian mistake in new test case. I missed a spot when adding the "#if __BYTE_ORDER__ == ..." guards to the new test case for PR tree-optimization/103345. Committed as obvious. 2021-11-30 Roger Sayle gcc/testsuite/ChangeLog PR testsuite/103477 * gcc.dg/tree-ssa/pr103345.c: Correct xor test for big-endian.
[Bug bootstrap/91972] Bootstrap should use -Wmissing-declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91972 --- Comment #7 from Alexander Monakov --- As I understand, only the gcc subdirectory changed implementation language from C to C++, so, yes (as far as this bug is concerned).
[Bug c/103491] New: nextafter does not raise "overflow" and "inexact" floating-point exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103491
Bug ID: 103491
Summary: nextafter does not raise "overflow" and "inexact"
floating-point exceptions
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pavel.morozkin at gmail dot com
Target Milestone: ---
Sample code (t0.c):
#include
#include
#pragma STDC FENV_ACCESS ON
int main(void)
{
#if __STDC_IEC_559__ == 1
double d = 1.0;
d = nextafter(d, INFINITY);
return (fetestexcept(FE_INEXACT | FE_INVALID) & (FE_INEXACT | FE_INVALID))
? 0 : 1;
#else
return 0;
#endif
}
Invocation: gcc -std=c11 -pedantic -Wall -Wextra -lm
Expected a.out exit status: 0
Actual a.out exit status: 1
C11, F.10.8.3 The nextafter functions:
> nextafter(x, y) raises the ‘‘overflow’’ and ‘‘inexact’’ floating-point
> exceptions for x finite and the function value infinite.
Yes, Pragma STDC * (C99 FP) is unimplemented
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20785). However, __STDC_IEC_559__
is already 1.
[Bug c/103492] New: 2 * new warnings in clang build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103492 Bug ID: 103492 Summary: 2 * new warnings in clang build Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- ../../trunk.git/gcc/fold-const-call.c:432:1: warning: non-void function does not return a value in all control paths [-Wreturn-type] ../../trunk.git/gcc/fold-const-call.c:465:1: warning: non-void function does not return a value in all control paths [-Wreturn-type] It looks like clang is being a bit keen. Suggest add a simple return false at the end of a couple of functions. Either that or start decorating the switch statements in some way.
[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943 --- Comment #30 from Aldy Hernandez --- (In reply to Jan Hubicka from comment #28) > Bit unrelated but shows that threader seems bit expensive on other builds > too. > Getting stats from cc1plus LTO-link with -flto-partition=one it seems that > backwards threader and dom are two slowest tree passes. > > We get > - 1% of build time for CCP, forward propagate, slp vectrization > - 2% of build time for cfgcleanup, VRP, PTA, PRE, FRE > - 3% of build time for dominator optimization > - 4% of build time for backwards jump threading > tree VRP : 29.83 ( 2%) 1.92 ( 3%) 32.77 ( > 2%) 354M ( 1%) ... ... > 3%) 566M ( 2%) > backwards jump threading : 49.72 ( 4%) 2.27 ( 3%) 53.04 ( This looks like the issue in PR103409. Does this fix the problem? https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585658.html
[Bug c/103492] 2 * new warnings in clang build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103492 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Given that the switch uses arg->cl expression which is an unsigned int cl : 2 bitfield and the switch has all the 4 values covered, that clearly looks like a clang bug. The gcc_unreachable () has been removed because of the -Wunreachable-code warnings...
[Bug c/103493] New: gcc crash with Seg fault signal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103493
Bug ID: 103493
Summary: gcc crash with Seg fault signal
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: k.even-mendoza at imperial dot ac.uk
Target Milestone: ---
Hi,
When trying to compile this code with GCC-12:
=
gcc -O0 prog.c
enum { a, b } main() {
(short)(b ^ (long)-(double)0 | 2 | (0 ^ (long)(double)0) * (0 % 0));
}
=
GCC crash with:
Please submit a full bug report,
gcc: internal compiler error: Segmentation fault signal terminated program cc1
GCC version
gcc (GCC) 12.0.0 2028 (experimental)
Unix/Ubuntu
[Bug ipa/103461] [12 Regression] ICE in operator_div::wi_fold or in evaluate_conditions_for_known_args since r12-5531-g1b0acc4b800b589a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103461 Paul Floyd changed: What|Removed |Added CC||pjfloyd at wanadoo dot fr --- Comment #5 from Paul Floyd --- I also get this if I try to build llvm with GCC git head.
[Bug ipa/103461] [12 Regression] ICE in operator_div::wi_fold or in evaluate_conditions_for_known_args since r12-5531-g1b0acc4b800b589a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103461 Aldy Hernandez changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #6 from Aldy Hernandez --- dup. also fixed by patch in PR103451. *** This bug has been marked as a duplicate of bug 103451 ***
[Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103451 --- Comment #10 from Aldy Hernandez --- *** Bug 103461 has been marked as a duplicate of this bug. ***
[Bug c++/103494] New: ice in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103494 Bug ID: 103494 Summary: ice in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1476 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 51906 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51906&action=edit gzipped C++ source code For the attached C++ code, with compiler flag -O3, does this: /home/dcb35/rpmbuild/BUILD/libvdpau-va-gl-0.4.2/src/api-output-surface.cc:448:1: internal compiler error: in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1476 448 | PutBitsIndexedImpl(VdpOutputSurface surface_id, VdpIndexedFormat source_indexed_format, | ^~ 0x1ff5137 vect_get_vec_defs_for_operand(vec_info*, _stmt_vec_info*, unsigned int, tree_node*, vec*, tree_node*) ../../trunk.git/gcc/tree-vect-stmts.c:1476 0x2014db1 vect_get_gather_scatter_ops(_loop_vec_info*, loop*, _stmt_vec_info*, _slp_tree*, unsigned int, gather_scatter_info*, tree_node**, vec*) ../../trunk.git/gcc/tree-vect-stmts.c:2981 The bug first seems to occur sometime between git hash 5e5f880d0452ef2c and 8af3f53d325fe4a6, a distance of 43 commits.
[Bug libstdc++/103305] Cannot build libstdc++ with newlib on aarch64-none-elf or bfin-elf with new version of newlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103305 --- Comment #20 from Tamar Christina --- Newlib ML thread https://sourceware.org/pipermail/newlib/2021/018706.html
[Bug target/103484] [12 Regression] ICE: in ix86_attr_length_immediate_default, at config/i386/i386.c:16686 with -O2 -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103484
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2021-11-30
Status|UNCONFIRMED |NEW
CC||aldyh at gcc dot gnu.org
--- Comment #2 from Aldy Hernandez ---
Confirmed.
(gdb) p debug(insn)
(insn 26 61 62 2 (parallel [
(set (reg:DI 0 ax [orig:99 _2 ] [99])
(ior:DI (lshiftrt:DI (reg:DI 0 ax [orig:99 _2 ] [99])
(const_int 0 [0]))
(subreg:DI (ashift:TI (zero_extend:TI (reg:DI 1 dx
[orig:102 _2+8 ] [102]))
(const_int 64 [0x40])) 0)))
(clobber (reg:CC 17 flags))
]) "a.c":10:38 731 {*x86_64_shrd_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (subreg:DI (ashift:TI (zero_extend:TI (reg:DI 1 dx
[orig:102 _2+8 ] [102]))
(const_int 64 [0x40])) 0)
(nil
$3 = void
(gdb) p len
$4 = 1
[Bug c++/103494] ice in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103494 --- Comment #1 from David Binderman --- I have a cvise reduction running right now. The code is C++, so it will take some time.
[Bug tree-optimization/103494] [12 Regression] ice in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103494 Andrew Pinski changed: What|Removed |Added Component|c++ |tree-optimization Summary|ice in |[12 Regression] ice in |vect_get_vec_defs_for_opera |vect_get_vec_defs_for_opera |nd, at |nd, at |tree-vect-stmts.c:1476 |tree-vect-stmts.c:1476 Keywords||ice-on-valid-code Target Milestone|--- |12.0
[Bug bootstrap/91972] Bootstrap should use -Wmissing-declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91972 Eric Gallager changed: What|Removed |Added Keywords||easyhack --- Comment #8 from Eric Gallager --- (In reply to Alexander Monakov from comment #7) > As I understand, only the gcc subdirectory changed implementation language > from C to C++, so, yes (as far as this bug is concerned). ok, that makes things simpler; adding the "easyhack" keyword (I might take a shot at this myself, but will stop short of self-assigning, since there's other things I'm focusing on currently)
[Bug middle-end/103493] gcc crash with Seg fault signal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103493 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 103314, fixed on the same day even as your GCC build. *** This bug has been marked as a duplicate of bug 103314 ***
[Bug middle-end/103314] [12 regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: Segmentation fault since r12-5358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103314 Andrew Pinski changed: What|Removed |Added CC||k.even-mendoza at imperial dot ac. ||uk --- Comment #10 from Andrew Pinski --- *** Bug 103493 has been marked as a duplicate of this bug. ***
[Bug c/103492] 2 * new warnings in clang build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103492 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- The gcc_unreachable called was explicitly removed in r12-5576-ga3b31fe3692894e8 . The bug is obvious in clang where the switch only can have 4 values as it is a load from a bitfield of size of 2 bits.
[Bug tree-optimization/99919] [9/10/11/12 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #3 from Aldy Hernandez ---
(In reply to Martin Sebor from comment #1)
> The IL below shows there is enough information in the IL for the warning to
> determine that x_5 is never read from.
>
> void g (struct B b)
> {
> _Bool b$j;
> _Bool b$i;
> _Bool x;
> unsigned char _1;
> unsigned char _2;
> unsigned char _3;
> unsigned char _4;
>
>[local count: 1073741824]:
> b$i_11 = b.i;
> _1 = VIEW_CONVERT_EXPR(b);
> _2 = _1 & 1;
> if (_2 != 0)
> goto ; [50.00%]
> else
> goto ; [50.00%]
>
>[local count: 536870912]:
>
>[local count: 1073741824]:
> # x_5 = PHI
> # b$j_10 = PHI <0(2), b$i_11(3)>
> b.j = b$j_10;
> _3 = VIEW_CONVERT_EXPR(b);
> _4 = _3 & 2;
> if (_4 != 0)
> goto ; [50.00%]
> else
> goto ; [50.00%]
>
>[local count: 536870913]:
> z = x_5;
>
>[local count: 1073741824]:
> return;
>
> }
The warning on the above IL seems legit.
x_5 is initialized from b$i_11 when b & 1 == 0, but the read from x_5 happens
when b & 2 != 0. So the set and the read are predicated on two different
things.
Maybe I'm missing some subtle bit field thing. Does setting b.j somehow alter
b.i?
[Bug tree-optimization/102467] Missed SLP discovery for gathers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102467 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #5 from rsandifo at gcc dot gnu.org --- Fixed for IFNs. Not sure whether we want to keep this open for the built-in route too.
[Bug tree-optimization/102467] Missed SLP discovery for gathers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102467 --- Comment #6 from rguenther at suse dot de --- On Tue, 30 Nov 2021, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102467 > > rsandifo at gcc dot gnu.org changed: > >What|Removed |Added > > CC||rsandifo at gcc dot gnu.org > > --- Comment #5 from rsandifo at gcc dot gnu.org > --- > Fixed for IFNs. Not sure whether we want to keep this open for > the built-in route too. I don't think so. The fix for the built-in route is to get rid of it. Of course I miserably failed at that - meh :/
[Bug tree-optimization/99919] [9/10/11/12 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-11-30 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Target Milestone|9.5 |13.0 Keywords||deferred --- Comment #4 from Andrew Pinski --- (In reply to Aldy Hernandez from comment #3) > The warning on the above IL seems legit. > > x_5 is initialized from b$i_11 when b & 1 == 0, but the read from x_5 > happens when b & 2 != 0. So the set and the read are predicated on two > different things. > > Maybe I'm missing some subtle bit field thing. Does setting b.j somehow > alter b.i? b.j is (b&2)<<1. If lower bit field acceses it is fixed (but also becomes more obvious what the of b.j is: _20 = VIEW_CONVERT_EXPR(b); _21 = BIT_INSERT_EXPR <_20, b$j_15, 1 (1 bits)>; VIEW_CONVERT_EXPR(b) = _21; _3 = VIEW_CONVERT_EXPR(b); _4 = _3 & 2; So Mine for GCC 13.
[Bug c++/103483] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103332 Ever confirmed|0 |1 Last reconfirmed||2021-11-30 --- Comment #2 from Jonathan Wakely --- (In reply to Andrew Pinski from comment #1) > I think the warning is correct really. It's wrong. > as if > d is a+1000 it is undefined. Without inlining there is no way to know if d > is any value. It's able to inline the size of the buffer all the way down to the char_traits::copy call, but isn't able to inline the length argument as well. If it can't use the compile-time constant length that is present in the code, it shouldn't bother doing these checks. The middle-end should not assume all code is wrong by default. These bogus stringop warnings in std::string are getting out of hand. See also PR103332 and others.
[Bug tree-optimization/99756] bogus -Wmaybe-uninitialized with a use conditional that's a subset of a defining conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99756
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||aldyh at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Aldy Hernandez ---
Fixed in trunk by one of the various improvements to the jump threader:
abulafia:~/bld/t/gcc$ ./cc1 a.c -O2 -Wall -quiet
abulafia:~/bld/t/gcc$ ./cc1 a.c -O2 -Wall -quiet -fno-thread-jumps
a.c: In function ‘f’:
a.c:10:10: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
10 | a[x] = 0; // { dg-bogus "Wmaybe-uninitialized" }
| ~^~~
a.c:5:7: note: ‘x’ was declared here
5 | int x;
| ^
abulafia:~/bld/t/gcc$
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 99756, which changed state. Bug 99756 Summary: bogus -Wmaybe-uninitialized with a use conditional that's a subset of a defining conditional https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99756 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/103491] nextafter does not raise "overflow" and "inexact" floating-point exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103491 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Keywords||wrong-code --- Comment #1 from Andrew Pinski --- The -O0 case is a glibc issue and should be reported there as gcc just calls nextafter function. The -O1 and above seems like a GCC issue though.
[Bug tree-optimization/103491] nextafter does not raise "overflow" and "inexact" floating-point exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103491 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-11-30 Component|middle-end |tree-optimization Status|UNCONFIRMED |NEW CC||jsm28 at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed with -frounding-math and optimization where we simply elide the nextafter call (and its side-effects). I think the idea is that -ftrapping-math should preserve such calls (but that's default on even). -frounding-math is documented to be required for FENV_ACCESS. Also confirmed as a glibc bug in 2.31 with -O0 where we call nextafter (). The manpage isn't too informative on whether your expectation is valid.
[Bug tree-optimization/103489] [12 Regression] ICE with -O3 in operator[], at vec.h:889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103489 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Priority|P3 |P1 Ever confirmed|0 |1 Target Milestone|--- |12.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2021-11-30 Keywords||needs-bisection --- Comment #1 from Richard Biener --- Confirmed. I'll have a look.
[Bug tree-optimization/103494] [12 Regression] ice in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103494
--- Comment #2 from David Binderman ---
$ more bug777.cc
void glFinish();
struct _Vector_base {
struct {
unsigned _M_start;
} _M_impl;
};
class vector : _Vector_base {
public:
vector(long) {}
unsigned *data() { return &_M_impl._M_start; }
};
void *PutBitsIndexedImpl_color_table;
int PutBitsIndexedImpl_dstRectHeight;
char *PutBitsIndexedImpl_src_ptr;
void PutBitsIndexedImpl() {
vector unpacked_buf(PutBitsIndexedImpl_dstRectHeight);
unsigned *dst_ptr = unpacked_buf.data();
for (int x; x; x++) {
char i = *PutBitsIndexedImpl_src_ptr++;
dst_ptr[x] = static_cast(PutBitsIndexedImpl_color_table)[i];
}
glFinish();
}
$
[Bug tree-optimization/103489] [12 Regression] ICE with -O3 in operator[], at vec.h:889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103489 Richard Biener changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101636 --- Comment #2 from Richard Biener --- So we BB vectorize sth we should use bool patterns to fixup. We get t.c:8:1: note: using normal nonmask vectors for a_I_lsm.24_70 = PHI <_54(D)(2), _208(4)> t.c:8:1: note: using boolean precision 16 for _208 = _207 != 0; but fail to add compensation on the PHI arg def because that's not supported right now. See also PR101636 for another bool pattern issue (but probably unrelated). So in this case the store is outside of a vectorized cycle (store motion is applied) and thus defined by a loop closed PHI node. check_bool_pattern doesn't handle this and thus we get to see we have a normal nonmask vector for the LC PHI: t.c:8:1: note: using normal nonmask vectors for a_I_lsm.24_20 = PHI but since we do not have patterns for PHIs the first nonmask use cannot get compensation code. The precision determining code in this case is broken since it does not handle cycles properly, we first visit the loop PHI having an external def and not yet visited backedge argument. I'm going to produce a fix for the ICE and think about fixing bool pattern detection for GCC 13.
[Bug tree-optimization/103489] [11/12 Regression] ICE with -O3 in operator[], at vec.h:889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103489 Richard Biener changed: What|Removed |Added Summary|[12 Regression] ICE with|[11/12 Regression] ICE with |-O3 in operator[], at |-O3 in operator[], at |vec.h:889 |vec.h:889 Target Milestone|12.0|11.3 --- Comment #3 from Richard Biener --- The issue should be latent on the GCC 11 branch as well.
[Bug tree-optimization/103495] New: vectorizer bool pattern recog does not handle cycles correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103495 Bug ID: 103495 Summary: vectorizer bool pattern recog does not handle cycles correctly Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- As can be seen in PR103489 bool pattern recog is defunct for cycle PHIs when we manage to visit the "wrong" def first.
[Bug tree-optimization/103489] [11/12 Regression] ICE with -O3 in operator[], at vec.h:889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103489 Richard Biener changed: What|Removed |Added Depends on||103495 --- Comment #4 from Richard Biener --- I've filed PR103495 for the bool pattern recog issue and will keep this bug for the ICE. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103495 [Bug 103495] vectorizer bool pattern recog does not handle cycles correctly
[Bug testsuite/103479] [12 regression] gcc.dg/bic-bitmask-18.c fails after r12-5489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103479 --- Comment #2 from seurer at gcc dot gnu.org --- Created attachment 51907 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51907&action=edit dec7 dump file Dump file attached
[Bug tree-optimization/103494] [12 Regression] ice in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103494 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-11-30 Ever confirmed|0 |1 Priority|P3 |P1 CC||rsandifo at gcc dot gnu.org --- Comment #3 from Richard Biener --- Confirmed. Likely caused by Richards SLP support patch though we get here w/o a SLP node. ncopies is "wrong" (or unsupported, the offset type is 'char'). I didn't implement widening for offset, maybe the change unleashed that somehow.
[Bug testsuite/103479] [12 regression] gcc.dg/bic-bitmask-18.c fails after r12-5489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103479 --- Comment #3 from Tamar Christina --- (In reply to seurer from comment #2) > Created attachment 51907 [details] > dec7 dump file > > Dump file attached Got it, thanks, I'll fix it today, the regexp is too liberal in this case.
[Bug lto/91288] [9/10/11/12 Regression] ICE in add_symbol_to_partition_1, at lto/lto-partition.c:153 since r249224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91288 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Martin Liška --- Fixed with r10-6111-g28307164dfed2948.
[Bug sanitizer/103466] [12 Regression] SIGILL on machine without avx support when using thread sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103466 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Martin Liška --- I'm planning one more merge from master, so it would be hopefully fixed by tah.
[Bug tree-optimization/103278] [12 Regression] Recent change to cddce inhibits switch optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103278 --- Comment #13 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:7e846b0f13b8a111484eb3a330044726b9d7ad79 commit r12-5625-g7e846b0f13b8a111484eb3a330044726b9d7ad79 Author: Martin Liska Date: Mon Nov 29 16:24:12 2021 +0100 Change if-to-switch-conversion test. PR tree-optimization/103278 gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/if-to-switch-5.c: Make the test acceptable by targets with no jump-tables.
[Bug tree-optimization/103278] [12 Regression] Recent change to cddce inhibits switch optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103278 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Martin Liška --- Fixed.
[Bug libstdc++/103453] ASAN detection with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103453 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug fortran/103496] New: [F2018][TS29113] C_SIZEOF – rejects now valid args with 'must be an interoperable data entity'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103496 Bug ID: 103496 Summary: [F2018][TS29113] C_SIZEOF – rejects now valid args with 'must be an interoperable data entity' Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- The following should now be fine – using an array descriptor as defined in TS29113 / F2018: 8 | print *, c_sizeof(a(:)) | 1 Error: ‘x’ argument of ‘c_sizeof’ intrinsic at (1) must be an interoperable data entity: Only whole-arrays are interoperable 12 | print *, c_sizeof(p) | 1 Error: ‘x’ argument of ‘c_sizeof’ intrinsic at (1) must be an interoperable data entity: Only explicit-size and assumed-size arrays are interoperable -- use iso_c_binding implicit none integer :: a(6) integer, pointer :: p(:) print *, c_sizeof(a) ! 6*4 - OK print *, c_sizeof(a(1))! 4 - OK print *, c_sizeof(a(:))! 6*4 - OK, rejected print *, c_sizeof(a(2::2)) ! 3*4 - rejected allocate(p(5)) print *, c_sizeof(p) ! 5*4 - rejected print *, c_sizeof(p(1))! 4 - OK print *, c_sizeof(p(:))! 5*4 - rejected print *, c_sizeof(p(2::2)) ! 2*4 - rejected end
[Bug tree-optimization/103489] [11/12 Regression] ICE with -O3 in operator[], at vec.h:889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103489 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:0194d92c35ca8b3aa850b805d9becb4491cf6bec commit r12-5626-g0194d92c35ca8b3aa850b805d9becb4491cf6bec Author: Richard Biener Date: Tue Nov 30 14:08:19 2021 +0100 tree-optimization/103489 - fix ICE when bool pattern recog fails bool pattern recog currently does not handle cycles correctly and when it fails we can ICE later vectorizing PHIs with mismatched bool and non-bool vector types. The following avoids blindly trusting bool pattern recog here and verifies things more thoroughly in vectorizable_phi. A bool pattern recog fix is for GCC 13. 2021-11-30 Richard Biener PR tree-optimization/103489 * tree-vect-loop.c (vectorizable_phi): Verify argument vector type compatibility to mitigate bool pattern recog bug. * gcc.dg/torture/pr103489.c: New testcase.
[Bug tree-optimization/103489] [11 Regression] ICE with -O3 in operator[], at vec.h:889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103489 Richard Biener changed: What|Removed |Added Summary|[11/12 Regression] ICE with |[11 Regression] ICE with |-O3 in operator[], at |-O3 in operator[], at |vec.h:889 |vec.h:889 --- Comment #6 from Richard Biener --- Fixed on trunk sofar, will backport as I think the issue is latent on the branch.
[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||law at gcc dot gnu.org --- Comment #3 from Aldy Hernandez --- I think we should start thinking of any Wuninitialized warnings in terms of missed threads, at least initially. Jeff has mentioned this in the past, an I'm slowly being converted. I mean, not that there aren't problems in the uninit code, but we should at least check that there are no missing threads. The problematic read from x is in BB5: [local count: 55807731]: h (x_17, y_2); y_16 = g (); goto ; [100.00%] On paths starting on 2->3 x_17 is defined, whereas on paths starting on 2->6 x_17 is undefined: [local count: 59055799]: # x_17 = PHI Looking at the last threader (threadfull2) before the uninit pass we see boths paths are registered for threading: [3] Registering jump thread: (3, 6) incoming edge; (6, 7) normal (7, 8) normal (8, 4) normal (4, 5) nocopy; [4] Registering jump thread: (2, 6) incoming edge; (6, 7) normal (7, 8) normal (8, 4) normal (4, 10) nocopy; However, there were no threaded paths in the entire compilation: $ grep thread a.c.338t.statistics $ So sometime between registering the path for threading and the lowlevel BB copier, we dropped the threads. The culprit is duplicate_thread_path in the generic bits: /* We do not handle subloops, i.e. all the blocks must belong to the same loop. */ if (region[i]->loop_father != loop) return false; This is an area I'm unfamiliar with, but it seems we should be able to thread this when loop optimizations are done. And indeed, if we allow this when loop_done, no warning is emitted.
[Bug tree-optimization/103440] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5522-g661c02e54ea72fb5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103440 --- Comment #4 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:e43b15c88c242b14a8ced8e631c1f9b80e83d63c commit r12-5628-ge43b15c88c242b14a8ced8e631c1f9b80e83d63c Author: Andrew MacLeod Date: Mon Nov 29 09:19:34 2021 -0500 Always track arguments, even when ignoring equiv params. To "ignore" ranges from equivalences, we should track the range separately, but still do the other name processing which determiens if there is a single name or not for equivalence. Otherwise we mistakently think we can introduce an equivalences. gcc/ PR tree-optimization/103440 * gimple-range-fold.cc (fold_using_range::range_of_phi): Continue normal param processing for equiv params. gcc/testsuite/ * gcc.dg/pr103440.c: New.
[Bug tree-optimization/103440] [12 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5522-g661c02e54ea72fb5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103440 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Andrew Macleod --- fixed.
[Bug tree-optimization/103489] [11 Regression] ICE with -O3 in operator[], at vec.h:889 since r12-5394-g0fc859f5efcb4624
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103489 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||marxin at gcc dot gnu.org Summary|[11 Regression] ICE with|[11 Regression] ICE with |-O3 in operator[], at |-O3 in operator[], at |vec.h:889 |vec.h:889 since ||r12-5394-g0fc859f5efcb4624 --- Comment #7 from Martin Liška --- Started with r12-5394-g0fc859f5efcb4624.
[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 --- Comment #4 from Aldy Hernandez --- Created attachment 51908 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51908&action=edit untested patch Like this. It fixes the problem at least for -O2.
[Bug fortran/103471] [9/10/11/12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103471 Martin Liška changed: What|Removed |Added CC||markeggleston at gcc dot gnu.org, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-11-30 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r7-4028-g87c9fca50cbe7ca9, was fixed in r10-7369-gc38daa7976886a59 and started again in r11-693-g3ea6977d0f1813d9.
[Bug fortran/103473] [11/12 Regression] ICE in simplify_minmaxloc_nodim, at fortran/simplify.c:5287
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103473 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Started with r12-4967-gbcf3728abe84.
[Bug fortran/103473] [11/12 Regression] ICE in simplify_minmaxloc_nodim, at fortran/simplify.c:5287
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103473 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Started with r12-4967-gbcf3728abe84. --- Comment #5 from Martin Liška --- Started with r12-4967-gbcf3728abe84.
[Bug tree-optimization/99919] [9/10/11/12 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919 --- Comment #5 from Aldy Hernandez --- (In reply to Andrew Pinski from comment #4) > (In reply to Aldy Hernandez from comment #3) > > The warning on the above IL seems legit. > > > > x_5 is initialized from b$i_11 when b & 1 == 0, but the read from x_5 > > happens when b & 2 != 0. So the set and the read are predicated on two > > different things. > > > > Maybe I'm missing some subtle bit field thing. Does setting b.j somehow > > alter b.i? > b.j is (b&2)<<1. > > If lower bit field acceses it is fixed (but also becomes more obvious what > the of b.j is: > _20 = VIEW_CONVERT_EXPR(b); > _21 = BIT_INSERT_EXPR <_20, b$j_15, 1 (1 bits)>; > VIEW_CONVERT_EXPR(b) = _21; > _3 = VIEW_CONVERT_EXPR(b); > _4 = _3 & 2; > > So Mine for GCC 13. You're a rockstar. Thanks.
[Bug testsuite/103477] [12 regression] gcc.dg/tree-ssa/pr103345.c fails after r12-5453
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103477 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Fixed.
[Bug tree-optimization/103494] [12 Regression] ice in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1476
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103494 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #4 from rsandifo at gcc dot gnu.org --- Mine.
[Bug c++/103478] Possible regression in constexpr processing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103478 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Started with r10-6417-g87fbd5347b338830.
[Bug tree-optimization/103489] [11 Regression] ICE with -O3 in operator[], at vec.h:889 since r12-5394-g0fc859f5efcb4624
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103489 --- Comment #8 from Richard Biener --- Huh, interestingly on the branch LIM eliminates all stores to a[] because the outer loop doesn't terminate (if it is entered). Not sure what "regressed" that optimization on trunk.
[Bug preprocessor/103488] cpp --help lists some options that are silently ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103488 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-11-30 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Confirmed.
[Bug ipa/103267] Wrong code with ipa-sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103267 --- Comment #10 from Martin Jambor --- I have proposed a patch to address this issue in: https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585756.html Well, it prevents the infinite loop testcase from segfaulting when the function infinite() is not declared with const attribute explicitely but it is only internally auto-discovered to be ECF_CONST. I think that is OK because explicit attribute const should guarantee no side-effects and infinite loop is IMHO one (though I have read how we document it in our manual and I am not entirely sure that is how we handle it, but IMHO the manual disallows infinite looping too). (We also discussed the post-dominance check with Honza in person and at least my impression is that the situation is not as dire as comment #9 might suggest.)
[Bug tree-optimization/103494] [12 Regression] ice in vect_get_vec_defs_for_operand, at tree-vect-stmts.c:1476 since r12-5612-g10833849b55401a52f2334eb032a70beb688e9fc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103494 Martin Liška changed: What|Removed |Added Summary|[12 Regression] ice in |[12 Regression] ice in |vect_get_vec_defs_for_opera |vect_get_vec_defs_for_opera |nd, at |nd, at |tree-vect-stmts.c:1476 |tree-vect-stmts.c:1476 ||since ||r12-5612-g10833849b55401a52 ||f2334eb032a70beb688e9fc CC||marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- Started with r12-5612-g10833849b55401a52f2334eb032a70beb688e9fc.
[Bug ipa/103449] [12 Regression] use-after-free in ipa_param_body_adjustments::prepare_debug_expressions(tree_node*) (ipa-param-manipulation.c:1283) since r12-4920-g1ece90ffa9ce63b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103449 --- Comment #7 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:b3f60112edcb85b459e60f66c44a55138b1cef49 commit r12-5630-gb3f60112edcb85b459e60f66c44a55138b1cef49 Author: Martin Jambor Date: Tue Nov 30 15:35:18 2021 +0100 ipa-param-manip: Be careful about a reallocating hash_map PR 103449 revealed that when I was storing result of one hash_map lookup into another entry in the hash_map, I was still accessing the entry in the table, which meanwhile could get reallocated, making the accesses invalid-after-free. Fixed with the following, which also simplifies the return statement which must have been true even now. gcc/ChangeLog: 2021-11-29 Martin Liska Martin Jambor PR ipa/103449 * ipa-param-manipulation.c (ipa_param_body_adjustments::prepare_debug_expressions): Be careful about hash_map reallocating itself. Simpify a return which always returns true.
[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 --- Comment #5 from Aldy Hernandez --- (In reply to Aldy Hernandez from comment #4) > Created attachment 51908 [details] > untested patch > > Like this. It fixes the problem at least for -O2. For -O1 y'all are on your own because there are no threaders smart enough to pick up the pattern. We'd need a threader at -O1 that runs after loop_done to pick it up: $ ./cc1 a.c -O1 -Wall -fenable-tree-threadfull2 -quiet cc1: note: enable pass tree-threadfull2 for functions in the range of [0, 4294967295] $ Voila, no warning. DOM3 runs after loop_done, so that would be candidate to handle this since it threads at -O1. However, this won't happen in this release. It would require a converting DOM threading to a hybrid approach (and see if the custom copier can handle cross-loop threading), or convert it entirely to the backward threader (would require ranger handling floats).
[Bug target/54063] [9/10/11/12 regression] on powerpc64 gcc 4.9/8 generates larger code for global variable accesses than gcc 4.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #22 from Roger Sayle --- I think this is now fixed on mainline? Alas godbolt doesn't provide a historical suite of GCC compilers for powerpc64, so figuring out exactly when this was resolved is non-trivial. However, a cross-compiler to powerpc64-linux-gnu currently generates the following for lookup with -O2: lookup: ld 8,.LC0@toc(2) ld 9,0(8) cmpd 0,9,8 bne 0,.L3 b .L4 .L8:ld 9,0(9) cmpd 0,9,8 beq 0,.L4 .L3:lwz 10,16(9) cmpw 0,10,3 bne 0,.L8 li 3,1 extsw 3,3 blr .L4:li 3,0 extsw 3,3 blr Only one mention of "toc". Apologies if this is an inappropriate metric.
[Bug ipa/103449] [12 Regression] use-after-free in ipa_param_body_adjustments::prepare_debug_expressions(tree_node*) (ipa-param-manipulation.c:1283) since r12-4920-g1ece90ffa9ce63b4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103449 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Jambor --- Fixed, thanks for reporting.
[Bug middle-end/61112] Simple example triggers false-positive -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61112 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||aldyh at gcc dot gnu.org --- Comment #10 from Aldy Hernandez --- the snippets in comment 1, 5, and 9 no longer warn on trunk.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 61112, which changed state. Bug 61112 Summary: Simple example triggers false-positive -Wmaybe-uninitialized warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61112 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/101912] -Wmaybe-uninitialized false alarm in tzdb localtime.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101912 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #2 from Aldy Hernandez --- ISTM that the warning is correct, given the IL the uninit pass gets. On the 7->3 entry to the loop prevcorr_23 can be undefined, and it is read in BB4 with no guard whatsoever: [local count: 85931698]: [local count: 1034442873]: # prevcorr_23 = PHI # leapcnt_24 = PHI corr_14 = getint (); if (corr_14 <= 0) goto ; [3.66%] else goto ; [96.34%] [local count: 37860610]: goto ; [100.00%] [local count: 996582262]: _1 = corr_14 == 1; _2 = leapcnt_24 != 0; _7 = (unsigned int) prevcorr_23; _5 = _7 + 4294967295; _4 = _5 > 1; _22 = _1 & _2; _18 = _4 & _22; if (_18 != 0) goto ; [1.21%] else goto ; [98.79%] However, in the original source we shouldn't read from prevcorr if leapcnt == 0, which is the case on entry to the loop: && !(leapcnt == 0 || (prevcorr < corr ? corr == prevcorr + 1 : (corr == prevcorr || corr == prevcorr - 1) It looks like we lost the leapcnt gate protecting the prevcorr_23 read. Unless I'm missing some subtle language thinggie, we loose the gate in the ifcombine pass. Before it, the read from prevcorr was protected by: [local count: 996582262]: _1 = corr_14 == 1; _2 = leapcnt_5 != 0; _3 = _1 & _2; if (_3 != 0) goto ; [50.00%] else goto ; [50.00%] and after ifcombine we have: [local count: 996582262]: _1 = corr_14 == 1; _2 = leapcnt_5 != 0; _3 = _1 & _2; _19 = prevcorr_4 != 1; _16 = _3 & _19; _21 = prevcorr_4 != 2; _18 = _16 & _21; if (_18 != 0) goto ; [1.21%] else goto ; [98.79%] Unfortunately, adding -fdisable-tree-ifcombine doesn't make the warning go away, but at least the IL by the uninit pass seems correct.
[Bug tree-optimization/103456] [12 Regression] gcc/gcc.c:9502:8: runtime error: load of address 0x0000009f5037 with insufficient space for an object of type 'const char' since r12-5548-g4a2007594cff78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103456
--- Comment #4 from Martin Liška ---
Reduced test-case that has a different output in optimized tree-dump:
$ cat gcc.i
static char *multilib_options = "m64/m32";
void used_arg_t() {
char *q = multilib_options;
for (;;) {
while (*q)
q++;
while (__builtin_strchr (q, '_') == 0)
while (*q)
q++;
}
}
[Bug target/103320] 12 Regression] Spec 2017 benchmark roms_r fails on PowerPC for -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103320 Michael Meissner changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Michael Meissner --- Note, roms_r is not compatible with -Ofast or -ffast-math unless you use the -fno-unsafe-math-optimizations option. I'm going to close the bug since I've adjusted my scripts to add that option to roms_r (and perlbench_r which also needs it).
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 103320, which changed state. Bug 103320 Summary: 12 Regression] Spec 2017 benchmark roms_r fails on PowerPC for -Ofast https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103320 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
