[Bug target/107949] New: PPC: Unnecessary rlwinm after lbzx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107949
Bug ID: 107949
Summary: PPC: Unnecessary rlwinm after lbzx
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
extern unsigned char magic1[256];
unsigned int hash(const unsigned char inp[4])
{
const unsigned long long INIT = 0x1ULL;
unsigned long long h1 = INIT;
h1 = magic1[((unsigned long long)inp[0]) ^ h1];
h1 = magic1[((unsigned long long)inp[1]) ^ h1];
h1 = magic1[((unsigned long long)inp[2]) ^ h1];
h1 = magic1[((unsigned long long)inp[3]) ^ h1];
return h1;
}
#ifdef __powerpc__
#define lbzx(b,c) ({ unsigned long long r; __asm__("lbzx
%0,%1,%2":"=r"(r):"b"(b),"r"(c)); r; })
unsigned int hash2(const unsigned char inp[4])
{
const unsigned long long INIT = 0x1ULL;
unsigned long long h1 = INIT;
h1 = lbzx(magic1, inp[0] ^ h1);
h1 = lbzx(magic1, inp[1] ^ h1);
h1 = lbzx(magic1, inp[2] ^ h1);
h1 = lbzx(magic1, inp[3] ^ h1);
return h1;
}
#endif
Extra rlwinm get added.
hash(unsigned char const*):
.LCF0:
addi 2,2,.TOC.-.LCF0@l
lbz 9,0(3)
addis 10,2,.LC0@toc@ha
ld 10,.LC0@toc@l(10)
lbz 6,1(3)
lbz 7,2(3)
lbz 8,3(3)
xori 9,9,0x1
lbzx 9,10,9
xor 9,9,6
rlwinm 9,9,0,0xff <= not necessary
lbzx 9,10,9
xor 9,9,7
rlwinm 9,9,0,0xff <= not necessary
lbzx 9,10,9
xor 9,9,8
rlwinm 9,9,0,0xff <= not necessary
lbzx 3,10,9
blr
.long 0
.byte 0,9,0,0,0,0,0,0
hash2(unsigned char const*):
.LCF1:
addi 2,2,.TOC.-.LCF1@l
lbz 7,0(3)
lbz 8,1(3)
lbz 10,2(3)
lbz 6,3(3)
addis 9,2,.LC1@toc@ha
ld 9,.LC1@toc@l(9)
xori 7,7,0x1
lbzx 7,9,7
xor 8,8,7
lbzx 8,9,8
xor 10,10,8
lbzx 10,9,10
xor 10,6,10
lbzx 3,9,10
rldicl 3,3,0,32
blr
Tiny sample:
unsigned long long tiny(const unsigned char *inp)
{
return inp[0] ^ inp[1];
}
tiny(unsigned char const*):
lbz 9,0(3)
lbz 10,1(3)
xor 3,9,10
rlwinm 3,3,0,0xff
blr
.long 0
.byte 0,9,0,0,0,0,0,0
unsigned long long tiny2(const unsigned char *inp)
{
unsigned long long a = inp[0];
unsigned long long b = inp[1];
return a ^ b;
}
tiny2(unsigned char const*):
lbz 9,0(3)
lbz 10,1(3)
xor 3,9,10
rlwinm 3,3,0,0xff
blr
.long 0
.byte 0,9,0,0,0,0,0,0
lbz/lbzx creates a value 0 <= x < 256. xor of 2 such values does not change
value range.
[Bug tree-optimization/107833] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833 --- Comment #11 from Richard Biener --- (In reply to Andrew Pinski from comment #10) > (In reply to Jakub Jelinek from comment #9) > > Wasn't this discussed in the past in other PRs? Whether uninitialized vars > > mean anything or anything but same value each time a SSA_NAME initialized to > > it is used? > > I think you are talking about PR 100810 and the discussions around the patch > that fixed that. Yep, it looks exactly like such a case - IVOPTs is replacing 'h' in the second inner loop with an expression based on 'i' and places the computation of 'h' before the early exit (because that's where the original 'h' IV PHI is defined). I think the placement doesn't make a difference but replacing the loop exit test does? Anyway, GCC doesn't ensure stability of uninitialized values which means any expressions derived become indeterminate, i_1(D) - i_1(D) isn't guaranteed to be zero if you obfuscate that a bit. That puts the burden on compiler passes to never introduce new intermediate values since whether any of the expression participating values are not initialized might only become visible later. OK, maybe that's too restrictive, but I certainly warned that the fix in PR100810 is going to be whack-a-mole playing. Here we have marking _19 as maybe-undef marking _44 as maybe-undef because of _19 but then we have [local count: 118111601]: # a.6_39 = PHI <_8(13), a.6_32(11)> # h_41 = PHI # i_44 = PHI g = 0; _1 = i_44 % 2; f.1_2 = f; if (a.6_39 < h_41) note how the use of i was hoisted which makes the /* Look for any uses of the maybe-unused SSA_NAME that dominates the block that reaches the incoming block corresponding to the PHI arg in which it is mentioned. That means we can assume the SSA_NAME is defined in that path, so we only mark a PHI result as maybe-undef if we find an unused reaching SSA_NAME. */ int idx = phi_arg_index_from_use (use_p); basic_block bb = gimple_phi_arg_edge (phi, idx)->src; if (ssa_name_any_use_dominates_bb_p (var, bb)) continue; logic fail. It's invariant motion that moves this use (I think we have a duplicate issue with regarding to -Wuninitialized for this kind of transform): _1 = i_44 % 2; invariant up to level 2, cost 20. ... Moving statement _1 = i_44 % 2; (cost 20) out of loop 2. We could try to use the same mark_ssa_maybe_undefs in invariant motion but it might not be a trivial exercise. I also question sustainability of how we extend exploitation of undefinedness in GCC ... :/
[Bug tree-optimization/107499] [13 Regression] 433.milc regressed by 6-8% on zen3 at -O2 -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107499 --- Comment #3 from Martin Liška --- > I'll wait for more > LNT results before investigating. See > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=465.70.0 Apparently, the numbers are good again now.
[Bug target/107920] [13 Regression] ICE in execute_todo, at passes.cc:2140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920 --- Comment #14 from prathamesh3492 at gcc dot gnu.org --- Posted patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607714.html Thanks, Prathamesh
[Bug c++/84469] structured binding inside for all loop thinks it is type depedent when it is not (inside a template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ee4f25999f6832a1c5060b9277222c03d852709a commit r13-4460-gee4f25999f6832a1c5060b9277222c03d852709a Author: Jakub Jelinek Date: Fri Dec 2 10:29:11 2022 +0100 c++: Deduce range for structured bindings if expression is not type dependent [PR84469] As shown on the decomp56.C testcase, if the range for expression when using structured bindings is not type dependent, we deduce the finish the structured binding types only when not in template (cp_convert_range_for takes care of that), but if in templates, do_range_for_auto_deduction is called instead and it doesn't handle structured bindings. During instantiation they are handled later, but during the parsing keeping the structured bindings type dependent when they shouldn't be changes behavior. The following patch calls cp_finish_decomp even from do_range_for_auto_deduction. The patch regresses the OpenMP g++.dg/gomp/for-21.C test (3 errors are gone), I'll post an incremental patch for it momentarily. 2022-12-02 Jakub Jelinek PR c++/84469 * parser.cc (do_range_for_auto_deduction): Add DECOMP_FIRST_NAME and DECOMP_CNT arguments. Call cp_finish_decomp if DECL is a structured binding. (cp_parser_range_for): Adjust do_range_for_auto_deduction caller. (cp_convert_omp_range_for): Likewise. * g++.dg/cpp1z/decomp56.C: New test. * g++.dg/gomp/pr84469.C: New test.
[Bug c++/84469] structured binding inside for all loop thinks it is type depedent when it is not (inside a template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f13305518558f20ef2d460a74eb29dad5fce1350 commit r13-4461-gf13305518558f20ef2d460a74eb29dad5fce1350 Author: Jakub Jelinek Date: Fri Dec 2 10:30:16 2022 +0100 c++: Incremental fix for g++.dg/gomp/for-21.C [PR84469] The PR84469 patch I've just posted regresses the for-21.C testcase, when in OpenMP loop there are at least 2 associated loops and in a template outer structured binding with non type dependent expression is used in the expressions of some inner loop, we don't diagnose those any longer, as the (weirdly worded) diagnostics was only done during finish_id_expression -> mark_used which for the inner loop expressions happens before the structured bindings are finalized. When in templates, mark_used doesn't diagnose uses of non-deduced variables, and if the range for expression is type dependent, it is similarly diagnosed during instantiation. But newly with the PR84469 fix if the range for expression is not type dependent, there is no place that would diagnose it, as during instantiation the structured bindings are already deduced. This patch ensures that the bug of using structured bindings from one associated loop in other associated loops is diagnosed by the c_omp_check_loop_iv code by ensuring that cp_finish_decomp is called already during cp_convert_omp_range_for if the artificial iterator has been successfully auto-deduced. 2022-12-02 Jakub Jelinek PR c++/84469 gcc/c-family/ * c-omp.cc (c_omp_is_loop_iterator): For range for with structured binding return TREE_VEC_LENGTH (d->declv) even if decl is equal to any of the structured binding decls. gcc/cp/ * parser.cc (cp_convert_omp_range_for): After do_auto_deduction if !processing_template_decl call cp_finish_decomp with processing_template_decl temporarily incremented. gcc/testsuite/ * g++.dg/gomp/for-21.C (f3, f6, f9): Adjust expected diagnostics. * g++.dg/gomp/for-22.C: New test.
[Bug target/107934] ICE: SIGSEGV in immediate_operand (recog.cc:1618) with -O2 -mtune=knl -ffinite-math-only and __bf16 since r13-4314-ga1ecc5600464f6a6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107934 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Liška --- Let's close it.
[Bug target/106577] [13 Regression] during RTL pass: subreg3 ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -O -mavx since r13-2006-ga56c1641e9d25e46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106577 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b3237a2c6847993f92218b65f96ece9831a8bfb0 commit r13-4462-gb3237a2c6847993f92218b65f96ece9831a8bfb0 Author: Jakub Jelinek Date: Fri Dec 2 11:08:45 2022 +0100 i386: Save/restore recog_data in ix86_vector_duplicate_value [PR106577] On Tue, Aug 16, 2022 at 09:14:06AM +0100, Richard Sandiford via Gcc-patches wrote: > IMO the correct low-effort fix is to save and restore recog_data > in ix86_vector_duplicate_value. It's a relatively big copy, > but the current code is pretty wasteful anyway (allocating at > least a new SET and INSN for every query). Compared to the > overhead of doing that, a copy to and from the stack shouldn't > be too bad. The following patch does that. It isn't the first spot in the compiler that does that, not even the first spot in the i386 backend. In i386-expand.cc beyond these 2 recog_memoized calls there is one in expand_vselect, but I think it is unlikely we'd run into these issues trying to expand new permutations from splitters. 2022-12-02 Jakub Jelinek PR target/106577 * config/i386/i386-expand.cc (ix86_vector_duplicate_value): Save/restore recog_data around recog_memoized calls. * gcc.target/i386/pr106577.c: New test.
[Bug testsuite/107903] new test case gcc.dg/analyzer/file-CWE-1341-example.c in r13-4218-g9ada45967b4cf5 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107903 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Last reconfirmed||2022-12-02 Host|powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||x86_64-linux-gnu Status|UNCONFIRMED |NEW Build|powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||x86_64-linux-gnu Target|powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||x86_64-linux-gnu --- Comment #1 from Martin Liška --- Confirmed on x86_64-linux-gnu as well.
[Bug analyzer/107396] [13 regression] new test case gcc.dg/analyzer/pipe-glibc.c in r13-3466-g792f039fc37faa fails with excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107396 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-12-02 Status|UNCONFIRMED |ASSIGNED Build|powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||x86_64-linux-gnu Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Target|powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||x86_64-linux-gnu Host|powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||x86_64-linux-gnu
[Bug tree-optimization/107833] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #12 from Jakub Jelinek ---
So, do we whack-a-mole in this case some more and try harder in
mark_ssa_maybe_undefs
by basically repeating the CCP4 UNDEFINED propagation, or invent some new stmt
or marking that IVOPTS could use before the loop to turn possibly undefined
into undefined but always the same random pattern within the same invocation
(kind of like asm ("" : "+g" (undef));), or something else (like after IVOPTS
stop the UNDEFINED propagation on loop header PHIs or something similar)?
[Bug target/106577] [13 Regression] during RTL pass: subreg3 ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -O -mavx since r13-2006-ga56c1641e9d25e46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106577 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug c++/84469] structured binding inside for all loop thinks it is type depedent when it is not (inside a template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84469 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Jakub Jelinek --- Fixed for GCC 13.
[Bug target/107949] PPC: Unnecessary rlwinm after lbzx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107949 --- Comment #1 from Jens Seifert --- hash2 is only provided to show how the code should look like (without rlwinm).
[Bug tree-optimization/107837] [10/11/12/13 Regression] Missed optimization: Using memcpy to load a struct unnecessary uses stack space since r8-5200
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107837 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jamborm at gcc dot gnu.org Priority|P3 |P2 Keywords|needs-bisection | Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression] |Missed optimization: Using |Missed optimization: Using |memcpy to load a struct |memcpy to load a struct |unnecessary uses stack |unnecessary uses stack |space |space since r8-5200 --- Comment #2 from Jakub Jelinek --- Started with r8-5200-gd90ffcfb7d105d004cf04911a42935be03256b49
[Bug testsuite/107046] [13 Regression] Recent FP range work causing inf-2 to be miscompiled on rx-elf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107046
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
(In reply to Jeffrey A. Law from comment #5)
> Given the magic hackery going on inside the RX target files, I wonder if we
> should skip the entire ieee suite for rx.
Doesn't add_options_for_ieee already handle RX though?
if { [istarget rx-*-*] } {
return "$flags -mnofpu"
}
ieee.exp repeats some of the add_options_for_ieee stuff and more though, so
shouldn't we
--- gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp.jj2022-01-11
23:11:22.969282018 +0100
+++ gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp 2022-12-02
12:15:22.307173074 +0100
@@ -52,6 +52,9 @@ if { [istarget "alpha*-*-*"]
|| [istarget "sh*-*-*"] } then {
lappend additional_flags "-mieee"
}
+if [istarget rx-*-*] then {
+ lappend additional_flags "-mnofpu"
+}
if { ![check_effective_target_signal] } {
lappend additional_flags "-DSIGNAL_SUPPRESS"
?
[Bug bootstrap/107950] New: partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950
Bug ID: 107950
Summary: partial LTO linking of libbackend.a:
gcc/gcc-rich-location.cc:207: undefined reference to
`range_label_for_type_mismatch::get_text(unsigned int)
const'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
If I use the patch candidate for PR107944 and do:
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 615a07089ee..e95390169cf 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2122,13 +2122,15 @@ selftest: $(SELFTEST_TARGETS)
# This is used only if the user explicitly asks for it.
compilations: $(BACKEND)
+$(foreach file,$(OBJS),$(eval CFLAGS-$(file) += -flto))
+
# This archive is strictly for the host.
libbackend.a: $(OBJS)
-rm -rf libbackend.a
@# Build libbackend.a as a thin archive if possible, as doing so
@# significantly reduces build times.
ifeq ($(USE_THIN_ARCHIVES),yes)
- $(AR) $(AR_FLAGS)T libbackend.a $(OBJS)
+ -$(LINKER) $^ -flinker-output=nolto-rel -r -o $@ -flto=auto
else
$(AR) $(AR_FLAGS) libbackend.a $(OBJS)
-$(RANLIB) $(RANLIB_FLAGS) libbackend.a
I get the following linker error:
$ make lto
g++ -no-pie -g -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 -fno-common
-DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o lto1 \
lto/lto-lang.o lto/lto.o lto/lto-object.o attribs.o lto/lto-partition.o
lto/lto-symtab.o lto/lto-common.o libbackend.a main.o libcommon-target.a
libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr
-lgmp -rdynamic -L./../zlib -lz -lzstd libcommon.a ../libcpp/libcpp.a
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a
/usr/bin/ld: libbackend.a: in function
`range_label_for_type_mismatch::range_label_for_type_mismatch(tree_node*,
tree_node*)':
/home/marxin/Programming/gcc2/gcc/gcc-rich-location.h:158: undefined reference
to `vtable for range_label_for_type_mismatch'
/usr/bin/ld: libbackend.a: in function
`maybe_range_label_for_tree_type_mismatch::get_text(unsigned int) const':
/home/marxin/Programming/gcc2/gcc/gcc-rich-location.cc:207: undefined reference
to `range_label_for_type_mismatch::get_text(unsigned int) const'
collect2: error: ld returned 1 exit status
make: *** [/home/marxin/Programming/gcc2/gcc/lto/Make-lang.in:96: lto1] Error 1
The error comes from gcc/gcc-rich-location.cc where we have:
label_text
maybe_range_label_for_tree_type_mismatch::get_text (unsigned range_idx) const
{
if (m_expr == NULL_TREE
|| !EXPR_P (m_expr))
return label_text::borrow (NULL);
tree expr_type = TREE_TYPE (m_expr);
tree other_type = NULL_TREE;
if (m_other_expr && EXPR_P (m_other_expr))
other_type = TREE_TYPE (m_other_expr);
range_label_for_type_mismatch inner (expr_type, other_type);
return inner.get_text (range_idx);
}
and yes, both symbols are undefined:
nm libbackend.a | grep range_label_for_type_mismatch
U _ZNK29range_label_for_type_mismatch8get_textEj
U _ZTV29range_label_for_type_mismatch
What's strange that also a normal build (non-LTO, no partial linking) has the
same definitions:
nm libbackend.a | grep range_label_for_type_mismatch
U _ZNK29range_label_for_type_mismatch8get_textEj
U _ZTV29range_label_for_type_mismatch
So any guess what can be bad?
[Bug bootstrap/107950] partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950 Martin Liška changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org Last reconfirmed||2022-12-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug bootstrap/107950] partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950 --- Comment #1 from Martin Liška --- Oh, the function has 2 different definitions in C and C++ FE: gcc/c/c-objc-common.cc:range_label_for_type_mismatch::get_text (unsigned /*range_idx*/) const gcc/cp/error.cc:range_label_for_type_mismatch::get_text (unsigned /*range_idx*/) const And so that's why I see the linker error for 'lto' binary, interesting..
[Bug middle-end/106805] [13 Regression] Undue optimisation of floating-point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 54004 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54004&action=edit gcc13-pr106805.patch Untested patch. I believe fold_relational_const does it right, in the match.pd case we are doing it just for simple_comparison, so a subset of those, so only ==/!= are quiet from those. Unfortunately, the patch isn't enough. On 12 branch it is enough until expansion but during expansion we just drop the comparisons for some reason, and on 13 branch it is worse, frange kicks in and we have the PR107608 problems.
[Bug sanitizer/107747] gcc trunk at -Os misses a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107747 Martin Liška changed: What|Removed |Added Resolution|--- |INVALID Status|ASSIGNED|RESOLVED --- Comment #2 from Martin Liška --- Can't reproduce, also GCC master reports the issue.
[Bug middle-end/106805] [13 Regression] Undue optimisation of floating-point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805 --- Comment #4 from Jakub Jelinek --- That said, perhaps for now committing the patch without the pr106805.c testcase and work incrementally on the other issues might be a good idea.
[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558 --- Comment #21 from Martin Liška --- *** Bug 107698 has been marked as a duplicate of this bug. ***
[Bug sanitizer/107698] ASAN misses a global-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107698 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Martin Liška --- Dup of PR106558, it's fixed now. *** This bug has been marked as a duplicate of bug 106558 ***
[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 Martin Liška changed: What|Removed |Added Target Milestone|--- |12.3
[Bug sanitizer/106739] [10/11/12/13 Regression] runtime error coredump case on c++17/20 since r11-2445-g8c00059ce058ea2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106739 --- Comment #3 from Jakub Jelinek --- Can't reproduce this, neither with 10, 11, 12 nor 2022-08-25ish trunk nor current trunk.
[Bug sanitizer/107586] gcc trunk missed a stack-buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107586
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|ASSIGNED|RESOLVED
--- Comment #2 from Martin Liška ---
If I hide the constant 70, then I get the error also with -O2:
diff -u pr107586-orig.c pr107586.c
--- pr107586-orig.c 2022-12-02 14:19:49.392836836 +0100
+++ pr107586.c 2022-12-02 14:19:33.096414298 +0100
@@ -3,13 +3,15 @@
int x;
};
+int N = 70;
+
void h(struct a *b)
{
struct a c[70];
int i;
-for (i = 0; i < 70; i++)
+for (i = 0; i < N; i++)
c[i].x = 1;
-__builtin_memcpy(b, c, 70*sizeof(struct a));
+__builtin_memcpy(b, c, N*sizeof(struct a));
__builtin_printf("%d\n", b->x);
};
void g()
So the compiler can propagate that, so closing as invalid.
[Bug fortran/106048] [10/11/12/13 Regression] ICE in ubsan_encode_value, at ubsan.cc:143 / verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106048 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/107833] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #13 from rguenther at suse dot de ---
On Fri, 2 Dec 2022, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
>
> --- Comment #12 from Jakub Jelinek ---
> So, do we whack-a-mole in this case some more and try harder in
> mark_ssa_maybe_undefs
> by basically repeating the CCP4 UNDEFINED propagation, or invent some new stmt
> or marking that IVOPTS could use before the loop to turn possibly undefined
> into undefined but always the same random pattern within the same invocation
> (kind of like asm ("" : "+g" (undef));), or something else (like after IVOPTS
> stop the UNDEFINED propagation on loop header PHIs or something similar)?
Given the implementation of mark_ssa_maybe_undefs we can either blame
(and fix) invariant motion (-fno-tree-loop-im fixes the testcase as well)
or remove the ssa_name_any_use_dominates_bb_p check in this function,
marking more SSA names as possibly undefined.
We can also choose to ignore the issue until we run into this in the
real world or try to design something better here (I keep being pointed
at LLVM here but I don't see them solving the issue either).
I will see whether I can make invariant motion not hoist undefined
names.
[Bug target/106462] LRA on mips64el: unable to reload (subreg:SI (reg:DI)) constrained by "f"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106462 --- Comment #5 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:70596a0fb2a2ec072e1e97e37616e05041dfa4e5 commit r13-4466-g70596a0fb2a2ec072e1e97e37616e05041dfa4e5 Author: Vladimir N. Makarov Date: Fri Dec 2 08:18:04 2022 -0500 LRA: Check hard reg availability of pseudo and its subreg for pseudo reload Do not reload subreg pseudo if there are hard regs for subreg mode but there are no hard regs for pseudo mode. PR target/106462 gcc/ChangeLog: * lra-constraints.cc (curr_insn_transform): Check available hard regs for pseudo and its subreg to decide what to reload. gcc/testsuite/ChangeLog: * gcc.target/mips/pr106462.c: New test.
[Bug c/107951] New: Invalid flexible array use not detected in nested structs by the C frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951
Bug ID: 107951
Summary: Invalid flexible array use not detected in nested
structs by the C frontend
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: siddhesh at gcc dot gnu.org
Target Milestone: ---
The following program:
typedef struct {
char pad;
char data[];
} F2;
typedef struct {
F2 flex;
unsigned pad;
} S2;
#define NULL (void *) 0
__SIZE_TYPE__
nested_flexarray (__SIZE_TYPE__ n)
{
S2 *p = __builtin_malloc (n);
return __builtin_dynamic_object_size (p->flex.data, 1);
}
ends up treating data[] as a zero sized array in C instead of flagging an
error. This is correctly handled in the C++ driver.
[Bug lto/107078] LTO is causing that firebird build is core dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 Martin Liška changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #14 from Martin Liška --- Can you please provide the exact steps on how to configure the project with the corresponding options and run the crashing command? I would like to attach a gdb to it.
[Bug sanitizer/106739] [10/11/12/13 Regression] runtime error coredump case on c++17/20 since r11-2445-g8c00059ce058ea2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106739 Martin Liška changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #4 from Martin Liška --- I also can't reproduce it.
[Bug tree-optimization/107833] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #14 from Richard Biener --- Created attachment 54005 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54005&action=edit patch for LIM I'm testing this patch to limit invariant motion which also fixes PR107839.
[Bug tree-optimization/107952] New: tree-object-size: inconsistent size for flexible arrays nested in structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
Bug ID: 107952
Summary: tree-object-size: inconsistent size for flexible
arrays nested in structs
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: siddhesh at gcc dot gnu.org
Target Milestone: ---
With -fstrict-flex-arrays, there is a clearer definition of what constitutes
flexible array members, controlled by the frontend. tree-object-size however
doesn't seem to handle this well enough when the flex array is nested. e.g.:
typedef struct {
char pad;
char data[8];
} F2;
typedef struct {
unsigned pad;
F2 flex;
} S2;
#define NULL (void *) 0
__SIZE_TYPE__
nested_flexarray (__SIZE_TYPE__ n)
{
S2 *p = (S2 *) __builtin_malloc (n);
return __builtin_dynamic_object_size (p->flex.data, 1);
}
__SIZE_TYPE__
nested_flexarray2 (S2 *p)
{
return __builtin_dynamic_object_size (p->flex.data, 1);
}
The current behaviour is to treat data as a flex array and nested_flexarray
returns the size as if it were a flex array. nested_flexarray2 however returns
the subscripted size, thinking of it as a fixed array, which should not be the
expected behaviour with -fstrict-flex-arrays=0. Instead it should return -1
for maximum size and perhaps 8 as minimum size.
If F2 is changed to:
typedef struct {
char pad;
char data[0];
} F2;
the current behaviour ends up returning 0 in both cases, which is incorrect.
Again, it should return the size as if it were a flex array in nested_flexarray
and -1 for maximum size for nested_flexarray2.
I have a patch that does this, but I need to fix up tests that currently expect
older behaviour and wanted to get some consensus before I fixed them up.
[Bug c++/105221] [10/11/12/13 Regression] gcc rejects true ? [](auto) noexcept {} : [](int) {} in C++17+ (works for C++14)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- P0012R1 added what is now http://eel.is/c++draft/temp.deduct.conv#5.2 , at that point: ``If the original A is a function pointer type, A can be "pointer to function" even if the deduced A is "pointer to noexcept function". If the original A is a pointer to member function type, A can be "pointer to member of type function" even if the deduced A is "pointer to member of type noexcept function".'' but I don't see in pt.cc anything keyed on DEDUCE_CONV that would deal with this.
[Bug c++/107622] Missing optimization of switch-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #9 from Martin Liška ---
So as was already said, -fstrict-enums is coarse-grained and can catch only a
situation like:
enum State {A, B, C};
...
void g(const State s) {
switch(s) {
...
case 257:
o = 13;
break;
orig.C:18:7: warning: case label value exceeds maximum value for type
[-Wswitch-outside-range]
18 | case 257:
| ^~~~
[Bug c++/107939] [11/12/13 Regression] Rejects use of `extern const` variable in a template since r11-557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Keywords|needs-bisection | Summary|[11/12/13 Regression] |[11/12/13 Regression] |Rejects use of `extern |Rejects use of `extern |const` variable in a|const` variable in a |template|template since r11-557 --- Comment #3 from Jakub Jelinek --- This is rejected since r11-557-gbeb019d346b903c16b9fd349937de444b6a8b6c0
[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767 --- Comment #4 from Martin Liška --- So the optimization is enabled after r13-1184-g57424087e82db140 where we newly convert if-else-if series to switch, that's later converted by switch conversion pass to the array lookup. Now the question is why the CSWITCH happens with -Os.
[Bug tree-optimization/107946] [13 Regression] 507.cactuBSSN_r regresses by ~9% on znver3 with PGO since r13-3875-g9e11ceef165bc0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107946 --- Comment #4 from Richard Biener --- The data found for other machines/flags is also rather inconclusive with ups and downs.
[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951 Richard Biener changed: What|Removed |Added Keywords||accepts-invalid CC||jsm28 at gcc dot gnu.org --- Comment #1 from Richard Biener --- > ./cc1 -quiet t.c -pedantic-errors t.c:7:6: error: invalid use of structure with flexible array member [-Wpedantic] 7 | F2 flex; | ^~~~ so this is supposedly a GCC extension, treating [] as [0] in this context?
[Bug c++/107622] Missing optimization of switch-statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek ---
If you use enum with fixed underlying type, then all the values of the
underlying type are valid, even with -fstrict-enums. Otherwise
namespace std {
enum class byte : unsigned char {};
}
couldn't work properly. Otherwise, with -fstrict-enums, enum { A, B, C } can
have
values 0, 1, 2, 3 and without -fstrict-enums all the values of the underlying
type.
See https://eel.is/c++draft/dcl.enum#8 for more details.
So, except for the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107622#c4 g
case where
we should have optimized it into constant I don't see any missed optimization
here.
[Bug c++/107938] [11/12/13 Regression] ICE directly returning `this` of `extern` variable in template since r11-557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107938 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13 Regression] ICE |[11/12/13 Regression] ICE |directly returning `this` |directly returning `this` |of `extern` variable in |of `extern` variable in |template|template since r11-557 Keywords|needs-bisection | CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- This also started with r11-557-gbeb019d346b903c16b9fd349937de444b6a8b6c0
[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767 --- Comment #5 from Коренберг Марк --- Not only -s problem. I think -O3 in gcc 12.2 will run faster than -O3 in gcc 13 (for this case). this code should not be treated as if-else-if-else-if. gcc 12 does its job right.
[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
--- Comment #6 from Martin Liška ---
> this code should not be treated as if-else-if-else-if.
Why? It's an equivalent representation as all ifs have a return statement. One
another equivalent representation is:
switch (dst_port)
{
case 15:
case 23:
case 47:
case 45:
case 42:
case 1:
case 2:
case 3:
return 1;
default:
return 0;
}
[Bug bootstrap/107950] partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950
--- Comment #2 from Richard Biener ---
I wonder why the linker complains? Isn't this like
t.h
class X { foo (); bar (); baz (); };
and splitting the foo/bar/baz implementations to three TUs and then linking
two of them partially?
That is, it looks like we reference the vtable but don't emit it here or
we end up with an ODR violation because somehow LTO thinks it can
privatize some of it?
[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Status|ASSIGNED|NEW
--- Comment #7 from Martin Liška ---
So what happens with the current master: we first convert the if-else-if series
to switch in iftoswitch pass:
dst_port_5 = MEM[(const uint16_t *)data_3(D) + 64B];
switch (dst_port_5) [INV], case 1: [INV], case 2:
[INV], case 3: [INV], case 15: [INV], case 23: [INV], case
42: [INV], case 45: [INV], case 47: [INV]>
:
:
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
:
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
:
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
:
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
:
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
:
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
:
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
:
// predicted unlikely by early return (on trees) predictor.
:
# _2 = PHI <1(4), 1(5), 1(3), 1(10), 1(9), 1(8), 1(7), 1(6), 0(2)>
then convert tree-switch-conversion which prefers bit test if possible.
However, the CFG is not collapsed and thus it fails due to:
bool
bit_test_cluster::is_beneficial (unsigned count, unsigned uniq)
{
return (((uniq == 1 && count >= 3)
|| (uniq == 2 && count >= 5)
|| (uniq == 3 && count >= 6)));
}
as count == 7. and so tree-switch-conversion happens. So one can mitigate that
with:
1) use switch statement instead of if series
2) reduce -param=switch-conversion-max-branch-ratio= that will not create so
big CSWTCH array
3) disable tree-switch-conversion pass
[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767 --- Comment #8 from Коренберг Марк --- Okay, but why switch-case is not handled using fast implementation using masks (when difference between smallest and biggest integer <=64 ? See the first function in my first message where it works as expected. Seems, the problem is not in converting to switch-case, but missing optimisation for switch-case case.
[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
--- Comment #9 from Jakub Jelinek ---
Indeed, comparing that to
int firewall3(const uint8_t *restrict data) {
const uint16_t dst_port = *((const uint16_t *)data + 32);
switch (dst_port) {
case 15: return 1;
case 23: return 1;
case 47: return 1;
case 45: return 1;
case 42: return 1;
case 1: return 1;
case 2: return 1;
case 3: return 1;
default: return 0;
}
}
this one is optimized correctly.
In iftoswitch dump this one is much simpler though:
dst_port_6 = MEM[(const uint16_t *)data_4(D) + 64B];
switch (dst_port_6) [INV], case 1 ... 3: [INV], case 15:
[INV], case 23: [INV], case 42: [INV], case 45: [INV],
case 47: [INV]>
:
:
:
# _3 = PHI <1(2), 0(3)>
:
return _3;
vs.
dst_port_5 = MEM[(const uint16_t *)data_3(D) + 64B];
switch (dst_port_5) [INV], case 1: [INV], case 2:
[INV], case 3: [INV], case 15: [INV], case 23: [INV], case
42: [INV], case 45:
[INV], case 47: [INV]>
:
:
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
:
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
:
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
:
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
:
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
:
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
:
// predicted unlikely by early return (on trees) predictor.
goto ; [INV]
:
:
// predicted unlikely by early return (on trees) predictor.
:
# _2 = PHI <1(4), 1(5), 1(3), 1(10), 1(9), 1(8), 1(7), 1(6), 0(2)>
:
return _2;
but I guess switchconv should be able to handle both the same.
[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767 --- Comment #10 from Richard Biener --- Looks like a general CFG optimization if we have N forwarders to a PHI with the same value then we can merge them to one (it's enough to have a single forwarder which we can use as the remaining one even). Note that's kind-of a reverse mergephi for same values. PHI -> forwarder | PHI CFG cleanup will then eventually elide forwarders into the added forwarder.
[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
--- Comment #11 from Jakub Jelinek ---
(In reply to Martin Liška from comment #7)
> However, the CFG is not collapsed and thus it fails due to:
>
> bool
> bit_test_cluster::is_beneficial (unsigned count, unsigned uniq)
> {
> return (((uniq == 1 && count >= 3)
> || (uniq == 2 && count >= 5)
> || (uniq == 3 && count >= 6)));
> }
>
> as count == 7. and so tree-switch-conversion happens. So one can mitigate
> that with:
> 1) use switch statement instead of if series
> 2) reduce -param=switch-conversion-max-branch-ratio= that will not create so
> big CSWTCH array
> 3) disable tree-switch-conversion pass
But that just means that either iftoswitch should happen earlier or switchconv
later
so that some other pass would remove the redundancies, or iftoswitch should
perform them when it optimizes something, or switchconv should not rely on the
collapsing being done already and do it itself.
In the #c9 testcase, it is cleanup_tree_cfg (TODO_update_ssa) during ccp1 pass
that optimizes it. But cleanup_tree_cfg (0) during iftoswitch for firewall2
doesn't do that for some reason.
[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #2 from qinzhao at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) > > ./cc1 -quiet t.c -pedantic-errors > t.c:7:6: error: invalid use of structure with flexible array member > [-Wpedantic] > 7 | F2 flex; > | ^~~~ > > so this is supposedly a GCC extension, treating [] as [0] in this context? I found this in the gcc doc: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html#Zero-Length "A structure containing a flexible array member, or a union containing such a structure (possibly recursively), may not be a member of a structure or an element of an array. (However, these uses are permitted by GCC as extensions.)" Looks like this usage is permitted by GCC extensions. However, cannot find the details in the doc on how GCC treat these usage.
[Bug tree-optimization/107767] [13 Regression] switch to table conversion happening even though using btq is better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107767
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #12 from Jakub Jelinek ---
(In reply to Richard Biener from comment #10)
> Looks like a general CFG optimization if we have N forwarders to a PHI with
> the same value then we can merge them to one (it's enough to have a single
> forwarder which we can use as the remaining one even). Note that's kind-of
> a reverse
> mergephi for same values.
>
> PHI
>
> ->
>
> forwarder
> |
> PHI
>
> CFG cleanup will then eventually elide forwarders into the added forwarder.
Are those actually forwarder blocks though?
Doesn't the GIMPLE_PREDICT statement at the start of each one of them prevent
tree_forwarder_block_p from returning true?
As a hack I've removed them manually:
FOR_EACH_BB_FN (bb, cfun)
{
gimple_stmt_iterator gsi = gsi_after_labels (bb);
if (!gsi_end_p (gsi) && gimple_code (gsi_stmt (gsi)) == GIMPLE_PREDICT)
gsi_remove (&gsi, true);
}
in pass_if_to_switch::execute before return TODO_cleanup_cfg;, but that didn't
help.
[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951 --- Comment #3 from Andrew Pinski --- r0-44662-g2984fe64968ad7 added that documentation. PR 15749 shows that at one point there was code floating around (glibc?) that uses the extension (_G_iconv_t).
[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=77650 --- Comment #4 from Andrew Pinski --- I think this is a duplicate of bug 77650. See there for more details.
[Bug rtl-optimization/107949] PPC: Unnecessary rlwinm after lbzx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107949
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-12-02
Component|target |rtl-optimization
Target|powerpc |powerpc, aarch64
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Andrew Pinski ---
aarch64 has the same issue (with almost the same RTL even)
(insn 6 3 7 2 (set (reg:QI 123 [ *inp_5(D) ])
(mem:QI (reg/v/f:SI 121 [ inp ]) [0 *inp_5(D)+0 S1 A8]))
"/app/example.cpp":4:17 554 {*movqi_internal}
(nil))
(insn 7 6 8 2 (set (reg:QI 124 [ MEM[(const unsigned char *)inp_5(D) + 1B] ])
(mem:QI (plus:SI (reg/v/f:SI 121 [ inp ])
(const_int 1 [0x1])) [0 MEM[(const unsigned char *)inp_5(D) +
1B]+0 S1 A8])) "/app/example.cpp":4:17 554 {*movqi_internal}
(expr_list:REG_DEAD (reg/v/f:SI 121 [ inp ])
(nil)))
(insn 8 7 9 2 (set (reg:SI 125)
(xor:SI (subreg:SI (reg:QI 123 [ *inp_5(D) ]) 0)
(subreg:SI (reg:QI 124 [ MEM[(const unsigned char *)inp_5(D) + 1B]
]) 0))) "/app/example.cpp":4:17 215 {*boolsi3}
(expr_list:REG_DEAD (reg:QI 124 [ MEM[(const unsigned char *)inp_5(D) +
1B] ])
(expr_list:REG_DEAD (reg:QI 123 [ *inp_5(D) ])
(nil
(note 9 8 21 2 NOTE_INSN_DELETED)
(insn 21 9 22 2 (set (reg:SI 3 3)
(const_int 0 [0])) "/app/example.cpp":5:1 549 {*movsi_internal1}
(nil))
(insn 22 21 17 2 (set (reg:SI 4 4 [orig:3+4 ] [3])
(zero_extend:SI (subreg:QI (reg:SI 125) 3))) "/app/example.cpp":5:1 4
{zero_extendqisi2}
(expr_list:REG_DEAD (reg:SI 125)
(nil)))
We lose track (didn't take into account LOAD_EXTEND_OP(QImode) is ZERO_EXTEND
?) that the memory was zero extended.
[Bug c++/107023] [10/11/12/13 Regression] [[gnu::stdcall]] Crashes the compiler, but __attribute__((stdcall)) and __stdcall worrks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107023
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
The ICE part with additional -g is fixed on the trunk with PR106937
r13-3202-g67efffec9436 fix.
Even just:
--- gcc/c-family/c-pretty-print.cc
+++ gcc/c-family/c-pretty-print.cc
@@ -901,7 +901,7 @@ pp_c_attributes_display (c_pretty_printer *pp, tree a)
{
pp_separate_with (pp, ',');
}
- pp_tree_identifier (pp, TREE_PURPOSE (a));
+ pp_tree_identifier (pp, get_attribute_name (a));
if (TREE_VALUE (a))
pp_c_call_argument_list (pp, TREE_VALUE (a));
}
would prevent the ICE.
I can't reproduce any
cc1plus: out of memory allocating 18446744073537494608 bytes after a total of
3219456 bytes
nor any issue without -g though.
[Bug c/77650] struct with a nested flexible array followed by another member accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650 Siddhesh Poyarekar changed: What|Removed |Added CC||siddhesh at gcc dot gnu.org --- Comment #6 from Siddhesh Poyarekar --- *** Bug 107951 has been marked as a duplicate of this bug. ***
[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951 Siddhesh Poyarekar changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Siddhesh Poyarekar --- (In reply to Andrew Pinski from comment #3) > r0-44662-g2984fe64968ad7 added that documentation. > PR 15749 shows that at one point there was code floating around (glibc?) > that uses the extension (_G_iconv_t). Yeah but it doesn't address bug 77650, which I agree that this is a duplicate of. Thanks for pointing out! *** This bug has been marked as a duplicate of bug 77650 ***
[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951 --- Comment #6 from qinzhao at gcc dot gnu.org --- after reading the history, my understanding is: this gcc extension is added as a workaround to build glibc since glibc source code has such usage of flexible array members; my question is: why not changing the glibc source code instead? then we don't need such workaround in GCC?
[Bug lto/107078] LTO is causing that firebird build is core dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 --- Comment #15 from Tomasz Kłoczko --- (In reply to Martin Liška from comment #14) > Can you please provide the exact steps on how to configure the project with > the corresponding options and run the crashing command? I would like to > attach a gdb to it. - take fedora firebird src.rpm and unpack it - undomment ins spec file disable LTO - build package
[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- (In reply to qinzhao from comment #6) > after reading the history, my understanding is: > > this gcc extension is added as a workaround to build glibc since glibc > source code has such usage of flexible array members; > > my question is: why not changing the glibc source code instead? then we > don't need such workaround in GCC? Because after all those years, you don't really know if it is just glibc (which likely doesn't do that anymore), but many other programs in the wild.
[Bug c/107951] Invalid flexible array use not detected in nested structs by the C frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951 --- Comment #8 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #7) > > Because after all those years, you don't really know if it is just glibc > (which likely doesn't do that anymore), but many other programs in the wild. Yes, Unfortunately that's the case. thanks.
[Bug c++/107953] New: Greater-than operator misparsed inside a lambda expression used as a template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107953
Bug ID: 107953
Summary: Greater-than operator misparsed inside a lambda
expression used as a template argument
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: majerech.o at gmail dot com
Target Milestone: ---
template
void
f() { }
constexpr auto g = f<[] (int x, int y) { return x > y; }>;
This produces the following diagnostic:
: In lambda function:
:5:50: error: expected ';' before '>' token
5 | constexpr auto g = f<[] (int x, int y) { return x > y; }>;
| ^~
| ;
:5:51: error: expected primary-expression before '>' token
5 | constexpr auto g = f<[] (int x, int y) { return x > y; }>;
| ^
ASM generation compiler returned: 1
: In lambda function:
:5:50: error: expected ';' before '>' token
5 | constexpr auto g = f<[] (int x, int y) { return x > y; }>;
| ^~
| ;
:5:51: error: expected primary-expression before '>' token
5 | constexpr auto g = f<[] (int x, int y) { return x > y; }>;
| ^
Godbolt link to the above: https://godbolt.org/z/KG6d5E6ev
Changing the body to return (x > y); makes the error go away as a workaround.
So I speculate that the greater-than operator is misparsed as the end of the
template argument list.
[Bug tree-optimization/107828] tree-inlining would generate SSA with incorrect def stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107828 --- Comment #2 from Martin Jambor --- I don't see any correctness issue here. It is true that when IPA-SRA needs to create a temporary SSA_NAME for an assignment with VIEW_CONVERT_EXPR (that is the only statement that extra_stmts can contain at the moment), the SSA_NAME then get's re-mapped to another while woe could have just re-use the existing one, it is already created within the new function. We could use the knowledge that extra_stmts is really only this one statement or nothing and avoid the remapping but that would be at the expense of universality and extensibility of the interface between tree-inline.cc and ipa-param-manipulations.cc. Please let me know if I am missing something (and preferably with a test-case that demonstrates the problem).
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 --- Comment #15 from anlauf at gcc dot gnu.org --- Created attachment 54006 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54006&action=edit Modified testcase I found that I get a hang on my system when I specify -fopenmp. It appears that there is a deadlock due to the evaluation of the merge arguments during the print. So changing the testcase as attached might fix the problem. Can you please verify?
[Bug lto/107078] LTO is causing that firebird build is core dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 --- Comment #16 from Martin Liška --- (In reply to Tomasz Kłoczko from comment #15) > (In reply to Martin Liška from comment #14) > > Can you please provide the exact steps on how to configure the project with > > the corresponding options and run the crashing command? I would like to > > attach a gdb to it. > > - take fedora firebird src.rpm and unpack it > - undomment ins spec file disable LTO > - build package I speak about direct use of the release tarball as I have almost no experience with Fedora packaging system. I can configure it and build and I also see the Segmenetation fault. However, I can't run the command manually: /tmp/firebird-4.0.2/gen/Release/firebird/bin/isql -q -i /tmp/firebird-4.0.2/src/dbs/metadata.sql can't format message 17:0 -- message file /usr/local/firebird/firebird.msg not found Unable to complete network request to host "localhost". -Failed to establish a connection. can't format message 17:120 -- message file /usr/local/firebird/firebird.msg not found
[Bug lto/107078] LTO is causing that firebird build is core dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 --- Comment #17 from Tomasz Kłoczko --- > /tmp/firebird-4.0.2/gen/Release/firebird/bin/isql -q -i > /tmp/firebird-4.0.2/src/dbs/metadata.sql > can't format message 17:0 -- message file /usr/local/firebird/firebird.msg > not found > Unable to complete network request to host "localhost". > -Failed to establish a connection. > can't format message 17:120 -- message file /usr/local/firebird/firebird.msg > not found This issue has nothing to do with running firebird. This issue is about compiler issue on linking firebird binary linked with LTO.
[Bug lto/107078] LTO is causing that firebird build is core dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107078 --- Comment #18 from Martin Liška --- > This issue is about compiler issue on linking firebird binary linked with > LTO. Good, so it's isql command that crashes: make gpre make[2]: Entering directory '/tmp/firebird-4.0.2/gen' rm -f metadata.fdb /tmp/firebird-4.0.2/gen/Release/firebird/bin/isql -q -i /tmp/firebird-4.0.2/src/dbs/metadata.sql make[2]: *** [Makefile:441: metadata.fdb] Segmentation fault (core dumped) make[2]: *** Deleting file 'metadata.fdb' make[2]: Leaving directory '/tmp/firebird-4.0.2/gen' make[1]: *** [Makefile:292: master_process] Error 2 And my question is, how run it under gdb?
[Bug bootstrap/107950] partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950
--- Comment #3 from Martin Liška ---
(In reply to Richard Biener from comment #2)
> I wonder why the linker complains? Isn't this like
>
> t.h
>
> class X { foo (); bar (); baz (); };
>
> and splitting the foo/bar/baz implementations to three TUs and then linking
> two of them partially?
I've just tried using -flto-partition=one and it hasn't helped me.
[Bug c++/103081] [ICE] with "using enum"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org
[Bug bootstrap/107950] partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950 --- Comment #4 from Jonathan Wakely --- The vtable will only be emitted in the TU containing the key function, which is that get_text function defined in the front end.
[Bug driver/107954] New: Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954 Bug ID: 107954 Summary: Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, I raise this ticket (I agree not very important, and more a feature request than a bug) following a similar one on C++/clang side and a remark from Aaron Ballman: https://github.com/llvm/llvm-project/issues/59300#issuecomment-1335623903 It seems that the future C2x standard has reached at least the feature freeze phase and the expectations are that it will be ratified in 2023. So, it is already the time to accept -std=c23/gnu23 as aliases of -std=c2x/gnu2x or is it early for this ? On C++ side gcc already accepts -std=c++23 since gcc 11 as now C++ standards seems to strictly follow the 3 years cadence. Cheers, Romain
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 --- Comment #16 from Jerry DeLisle --- (In reply to anlauf from comment #15) --- snip --- > Can you please verify? Yes, this fixes the test case. However if the orginal test case is valid fortran we probably need to fix something else. Paul Thomas was noticing a similar problem with his Finalization patches. He was doing the finalization inside trans_transfer or similar so it was blocking on a mutex trying to finalize in the middle of an I/O operation. So in this case, my guess is the merge expression needs to be resolved before the translation phase.
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #16)
> (In reply to anlauf from comment #15)
> --- snip ---
> > Can you please verify?
>
> Yes, this fixes the test case.
OK, thanks for confirming.
> However if the orginal test case is valid
> fortran we probably need to fix something else. Paul Thomas was noticing a
> similar problem with his Finalization patches. He was doing the
> finalization inside trans_transfer or similar so it was blocking on a mutex
> trying to finalize in the middle of an I/O operation.
>
> So in this case, my guess is the merge expression needs to be resolved
> before the translation phase.
If I interprete the tree-dump correctly, we have e.g.:
_gfortran_st_write (&dt_parm.2);
{
logical(kind=4) D.4279;
logical(kind=4) D.4280;
logical(kind=4) D.4281;
logical(kind=4) D.4282;
D.4279 = tstuff ();
D.4280 = fstuff ();
D.4281 = x[(integer(kind=8)) i + -1];
D.4282 = D.4281 ? D.4279 : D.4280;
_gfortran_transfer_logical_write (&dt_parm.2, &D.4282, 4);
}
_gfortran_st_write_done (&dt_parm.2);
so we start the write, then evaluate the merge(), which is tstuff()/fstuff(),
and which does its own I/O, and then return to continue with the transfer.
So this might be non-conforming code, see
F2018:12.12 Restrictions on input/output statements
(2) An input/output statement that is executed while another input/output
statement is being executed is a recursive input/output statement.
A recursive input/output statement shall not identify an external unit that
is identified by another input/output statement being executed except that
a child data transfer statement may identify its parent data transfer
statement external unit.
I am not sure I fully understand the last sentence in this paragraph,
but I think the pushed testcase might be invalid and should be replaced.
If you agree, I'll simply do this.
[Bug c++/88434] [DR1835] operator< should take precedence over template argument in basic.lookup.classref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88434 Andrew Pinski changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #5 from Andrew Pinski --- > [Accepted at the November, 2020 meeting as part of paper P1787R6 and moved to > DR at the February, 2021 meeting.]
[Bug c++/107953] Greater-than operator misparsed inside a lambda expression used as a template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107953 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=57 --- Comment #1 from Andrew Pinski --- I suspect this is the same issue as PR 57 .
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
--- Comment #18 from john.harper at vuw dot ac.nz ---
An interesting problem! But I thought my original test case did not have
recursive I/O because tstuff and fstuff each print something in the
statement
y = merge(tstuff(),fstuff(),x(i))
but y itself is printed only in the next statement,
print *,y
Or does evaluating merge allow each of tstuff and fstuff to be evaluated
at the same time? I was thinking of tstuff and fstuff being evaluated
in succession but could there be systems in which they are evaluated
simultaneously? If so, whether the program is valid Fortran depends on the
kind of system on which it is being executed.
John Harper
On Fri, 2 Dec 2022, anlauf at gcc dot gnu.org wrote:
> Date: Fri, 2 Dec 2022 20:22:23 +
> From: anlauf at gcc dot gnu.org
> To: John Harper
> Subject: [Bug fortran/107874] merge not using all its arguments
> Resent-Date: Sat, 3 Dec 2022 09:22:36 +1300 (NZDT)
> Resent-From:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
>
> --- Comment #17 from anlauf at gcc dot gnu.org ---
> (In reply to Jerry DeLisle from comment #16)
>> (In reply to anlauf from comment #15)
>> --- snip ---
>>> Can you please verify?
>>
>> Yes, this fixes the test case.
>
> OK, thanks for confirming.
>
>> However if the orginal test case is valid
>> fortran we probably need to fix something else. Paul Thomas was noticing a
>> similar problem with his Finalization patches. He was doing the
>> finalization inside trans_transfer or similar so it was blocking on a mutex
>> trying to finalize in the middle of an I/O operation.
>>
>> So in this case, my guess is the merge expression needs to be resolved
>> before the translation phase.
>
> If I interprete the tree-dump correctly, we have e.g.:
>
> _gfortran_st_write (&dt_parm.2);
> {
>logical(kind=4) D.4279;
>logical(kind=4) D.4280;
>logical(kind=4) D.4281;
>logical(kind=4) D.4282;
>
>D.4279 = tstuff ();
>D.4280 = fstuff ();
>D.4281 = x[(integer(kind=8)) i + -1];
>D.4282 = D.4281 ? D.4279 : D.4280;
>_gfortran_transfer_logical_write (&dt_parm.2, &D.4282, 4);
> }
> _gfortran_st_write_done (&dt_parm.2);
>
> so we start the write, then evaluate the merge(), which is tstuff()/fstuff(),
> and which does its own I/O, and then return to continue with the transfer.
>
> So this might be non-conforming code, see
>
> F2018:12.12 Restrictions on input/output statements
>
> (2) An input/output statement that is executed while another input/output
> statement is being executed is a recursive input/output statement.
> A recursive input/output statement shall not identify an external unit that
> is identified by another input/output statement being executed except that
> a child data transfer statement may identify its parent data transfer
> statement external unit.
>
> I am not sure I fully understand the last sentence in this paragraph,
> but I think the pushed testcase might be invalid and should be replaced.
>
> If you agree, I'll simply do this.
>
> --
> You are receiving this mail because:
> You reported the bug.
>
-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99576 Iain Sandoe changed: What|Removed |Added Target Milestone|--- |10.5 --- Comment #15 from Iain Sandoe --- revised patch https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607776.html
[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-02 Keywords||diagnostic, ||internal-improvement Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. The following options (and maybe some in the diagnostic messages too) need to be changed/aliased: Wc11-c2x-compat std=c2x Internally the macros: D_C2X STD_C2X CLK_STDC2X CLK_GNUC2X the language name: c-opts.cc: lang_hooks.name = "GNU C2X"; And a few other places. It is early in stage 4 of GCC 13 release cycle but I will leave it up to the C maintainers to see if they want the change for GCC 13 or wait till stage 1 of GCC 14. Confirmed otherwise.
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 --- Comment #19 from anlauf at gcc dot gnu.org --- (In reply to john.harper from comment #18) > An interesting problem! But I thought my original test case did not have > recursive I/O because tstuff and fstuff each print something in the > statement > y = merge(tstuff(),fstuff(),x(i)) > but y itself is printed only in the next statement, > print *,y John, your original testcase in comment#0 was fine. I tried to extend it to check for constant as well as non-constant mask, and as you see I made a mistake by trying to make it smaller. Bad idea. > Or does evaluating merge allow each of tstuff and fstuff to be evaluated > at the same time? I was thinking of tstuff and fstuff being evaluated > in succession but could there be systems in which they are evaluated > simultaneously? I don't recall having seen a mentioning in the standard of the order of evaluation of different function (or subroutine) arguments. Do you? (Of course, if side-effects happen during that evaluation, such as I/O, unexpected things may happen.) > If so, whether the program is valid Fortran depends on the > kind of system on which it is being executed. Well, even if the print in tstuff/fstuff were a problem, one could construct other testcases with side-effects that might be conforming.
[Bug bootstrap/107950] partial LTO linking of libbackend.a: gcc/gcc-rich-location.cc:207: undefined reference to `range_label_for_type_mismatch::get_text(unsigned int) const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107950 --- Comment #5 from Andrew Pinski --- It might be the case the object files were unused in the archive so they are not linked in the LTO front-end but now with using LTO partial linking, they are pulled in always.
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 --- Comment #20 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #19) > I don't recall having seen a mentioning in the standard of the order of > evaluation of different function (or subroutine) arguments. Do you? The closest I can find is the following in F2018: C.5.1 Evaluation of function references (10.1.7) (1) If more than one function reference appears in a statement, they can be executed in any order (subject to a function result being evaluated after the evaluation of its arguments) and their values cannot depend on the order of execution. This lack of dependence on order of evaluation enables parallel execution of the function references. And: A.2 Processor dependencies According to this document, the following are processor dependent: ... • the order of finalization of components of objects of derived type (7.5.6.2) • the order of finalization when several objects are finalized as the consequence of a single event (7.5.6.2);
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 --- Comment #21 from john.harper at vuw dot ac.nz --- I now have a new test case that avoids the possibility of recursive I/O by tstuff and fstuff doing internal writes to two different character variables. It still reveals the merge problem. It compiles and runs with gfortran-12 and ifort, giving different outputs. ! Must merge evaluate all 3 arguments? program testmerge10 implicit none character(7):: string(2) = ' ' logical:: x(2) = [.true., .false.], y integer i do i = 1,2 y = merge(tstuff(),fstuff(),x(i)) print *,y,string string = ' ' end do contains logical function tstuff() write(string(1),"(A)") ' tstuff' tstuff = .true. end function tstuff logical function fstuff() write(string(2),"(A)") ' fstuff' fstuff = .false. end function fstuff end program testmerge10 Good luck with your bughunt! John H On Fri, 2 Dec 2022, anlauf at gcc dot gnu.org wrote: > Date: Fri, 2 Dec 2022 21:05:43 + > From: anlauf at gcc dot gnu.org > To: John Harper > Subject: [Bug fortran/107874] merge not using all its arguments > Resent-Date: Sat, 3 Dec 2022 10:05:53 +1300 (NZDT) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 > > --- Comment #19 from anlauf at gcc dot gnu.org --- > (In reply to john.harper from comment #18) >> An interesting problem! But I thought my original test case did not have >> recursive I/O because tstuff and fstuff each print something in the >> statement >> y = merge(tstuff(),fstuff(),x(i)) >> but y itself is printed only in the next statement, >> print *,y > > John, your original testcase in comment#0 was fine. > I tried to extend it to check for constant as well as non-constant mask, > and as you see I made a mistake by trying to make it smaller. Bad idea. > >> Or does evaluating merge allow each of tstuff and fstuff to be evaluated >> at the same time? I was thinking of tstuff and fstuff being evaluated >> in succession but could there be systems in which they are evaluated >> simultaneously? > > I don't recall having seen a mentioning in the standard of the order of > evaluation of different function (or subroutine) arguments. Do you? > > (Of course, if side-effects happen during that evaluation, such as I/O, > unexpected things may happen.) > >> If so, whether the program is valid Fortran depends on the >> kind of system on which it is being executed. > > Well, even if the print in tstuff/fstuff were a problem, one could construct > other testcases with side-effects that might be conforming. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276
[Bug analyzer/107851] Issues with -Wanalyzer-allocation-size messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107851
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:f5758fe5b430ef3447fbab947fcea32a1d995f36
commit r13-4471-gf5758fe5b430ef3447fbab947fcea32a1d995f36
Author: David Malcolm
Date: Fri Dec 2 16:30:51 2022 -0500
analyzer: fixes to region creation messages [PR107851]
In r13-2573-gc81b60b8c6ff3d I split up the analyzer's region-creation
events to describe the memory space and capacity of the region as two
separate events to avoid combinatorial explosion of message wordings.
However I didn't take into account r13-1405-ge6c3bb379f515b which
added a pending_diagnostic::describe_region_creation_event vfunc which
could change the wording of region creation events.
Hence for:
#include
#include
void test ()
{
int32_t *ptr = malloc (1);
free (ptr);
}
trunk currently emits:
Compiler Explorer (x86_64 trunk): https://godbolt.org/z/e3Td7c9s5:
: In function 'test':
:6:18: warning: allocated buffer size is not a multiple of the
pointee's size [CWE-131] [-Wanalyzer-allocation-size]
6 | int32_t *ptr = malloc (1);
| ^~
'test': events 1-3
|
|6 | int32_t *ptr = malloc (1);
| | ^~
| | |
| | (1) allocated 1 bytes here
| | (2) allocated 1 bytes here
| | (3) assigned to 'int32_t *' {aka 'int *'}
here; 'sizeof (int32_t {aka int})' is '4'
|
where events (1) and (2) are different region_creation_events that have
had their wording overridden (also, with a "1 bytes" issue).
This patch reorganizes region creation events so that each
pending_diagnostic instead creates the events that is appropriate for it,
and the events have responsibility for their own wording.
With this patch, the above emits:
: In function 'test':
:6:18: warning: allocated buffer size is not a multiple of the
pointee's size [CWE-131] [-Wanalyzer-allocation-size]
6 | int32_t *ptr = malloc (1);
| ^~
'test': events 1-2
|
|6 | int32_t *ptr = malloc (1);
| | ^~
| | |
| | (1) allocated 1 byte here
| | (2) assigned to 'int32_t *' {aka 'int *'}
here; 'sizeof (int32_t {aka int})' is '4'
|
fixing the duplicate event, and fixing the singular/plural issue.
gcc/analyzer/ChangeLog:
PR analyzer/107851
* analyzer.cc (make_label_text_n): Convert param "n" from int to
unsigned HOST_WIDE_INT.
* analyzer.h (make_label_text_n): Likewise for decl.
* bounds-checking.cc: Include "analyzer/checker-event.h" and
"analyzer/checker-path.h".
(out_of_bounds::add_region_creation_events): New.
(concrete_past_the_end::describe_region_creation_event): Replace
with...
(concrete_past_the_end::add_region_creation_events): ...this.
(symbolic_past_the_end::describe_region_creation_event): Delete.
* checker-event.cc (region_creation_event::region_creation_event):
Update for dropping all member data.
(region_creation_event::get_desc): Delete, splitting out into
region_creation_event_memory_space::get_desc,
region_creation_event_capacity::get_desc, and
region_creation_event_debug::get_desc.
(region_creation_event_memory_space::get_desc): New.
(region_creation_event_capacity::get_desc): New.
(region_creation_event_allocation_size::get_desc): New.
(region_creation_event_debug::get_desc): New.
* checker-event.h: Include "analyzer/program-state.h".
(enum rce_kind): Delete.
(class region_creation_event): Drop all member data.
(region_creation_event::region_creation_event): Make protected.
(region_creation_event::get_desc): Delete.
(class region_creation_event_memory_space): New.
(class region_creation_event_capacity): New.
(class region_creation_event_allocation_size): New.
(class region_creation_event_debug): New.
* checker-path.cc (checker_path::add_region_creation_events): Add
"pd" param. Call pending_diangnostic::add_region_creation_events.
Update for conversion of RCE_DEBUG to region_creation_event_debug.
* checker-path.h (checker_path::add_region_creation_events): Add
"pd" param.
* diagnostic-manager.cc (diagnostic_manager::build_emission_path):
Pass pending_diagnostic to
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 --- Comment #22 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:36a4ee406b95ae24a59b8b3f8ebe29af6fd5261e commit r13-4473-g36a4ee406b95ae24a59b8b3f8ebe29af6fd5261e Author: Harald Anlauf Date: Fri Dec 2 22:30:16 2022 +0100 Fortran: intrinsic MERGE shall use all its arguments [PR107874] gcc/testsuite/ChangeLog: PR fortran/107874 * gfortran.dg/merge_1.f90: Avoid recursive I/O.
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 --- Comment #23 from Jerry DeLisle --- John, Your original case in Comment 1 now gives: $ gfc original.f90 $ ./a.out tstuff fstuff T tstuff fstuff F So I think it is OK, Harald's test case has function calls embedded in the print statements within the main program and those functions have embedded print statements themselves to the same output device which is stdout and this is not allowed per the Fortran standard. So the issue is only in the test case he previously committed and it is now fixed.
[Bug analyzer/107851] Issues with -Wanalyzer-allocation-size messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107851 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2022-12-02 --- Comment #2 from David Malcolm --- The above patch fixes the repeated events, but doesn't fix the repeated diagnostics. Keeping open to track fixing the latter; see: gcc/testsuite/gcc.dg/analyzer/allocation-size-multiline-2.c
[Bug c++/107953] Greater-than operator misparsed inside a lambda expression used as a template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107953 --- Comment #2 from Andrew Pinski --- Even template defaults has issues: template y; }> int t = 0; Which is why I Pointed to PR 57.
[Bug c++/107953] Greater-than operator misparsed inside a lambda expression used as a template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107953 --- Comment #3 from Andrew Pinski --- I wonder if this is still an ambiguous part of the C++ grammar and all.
[Bug c++/107953] Greater-than operator misparsed inside a lambda expression used as a template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107953 --- Comment #4 from Ondřej Majerech --- It seems that the core of PR 57 is that `A
[Bug analyzer/107948] GCC Static Analyzer doesn't realize `0 - width <= 0` is always true when `width > 0` and `width is int` type，
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107948 --- Comment #3 from Geoffrey --- (In reply to CVS Commits from comment #1) > The master branch has been updated by David Malcolm : > > https://gcc.gnu.org/g:0b737090a69624dea5318c380620283f0321a92e > > commit r13-4456-g0b737090a69624dea5318c380620283f0321a92e > Author: David Malcolm > Date: Thu Dec 1 21:28:55 2022 -0500 > > analyzer: handle comparisons against negated symbolic values [PR107948] > > gcc/analyzer/ChangeLog: > PR analyzer/107948 > * region-model-manager.cc > (region_model_manager::maybe_fold_binop): Fold (0 - VAL) to -VAL. > * region-model.cc (region_model::eval_condition): Handle e.g. > "-X <= 0" as equivalent to X >= 0". > > gcc/testsuite/ChangeLog: > PR analyzer/107948 > * gcc.dg/analyzer/feasibility-pr107948.c: New test. > > Signed-off-by: David Malcolm Thanks for your effort!
