[Bug sanitizer/105235] [11/12 Regression] ICE: in redirect_eh_edge_1, at tree-eh.cc:2323 with custom flags since r11-4519-g53dede0f04bd95c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105235 Martin Liška changed: What|Removed |Added CC||aoliva at gcc dot gnu.org Summary|[12 Regression] ICE: in |[11/12 Regression] ICE: in |redirect_eh_edge_1, at |redirect_eh_edge_1, at |tree-eh.cc:2323 with custom |tree-eh.cc:2323 with custom |flags |flags since ||r11-4519-g53dede0f04bd95c3 Ever confirmed|0 |1 Last reconfirmed||2022-04-12 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Liška --- With -c -O -fno-tree-dominator-opts -fnon-call-exceptions -fexceptions -fsanitize=thread -fno-tree-fre it started with r11-4519-g53dede0f04bd95c3.
[Bug sanitizer/105235] [11/12 Regression] ICE: in redirect_eh_edge_1, at tree-eh.cc:2323 with custom flags since r11-4519-g53dede0f04bd95c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105235 --- Comment #3 from Zdenek Sojka --- (In reply to Martin Liška from comment #2) > With -c -O -fno-tree-dominator-opts -fnon-call-exceptions -fexceptions > -fsanitize=thread -fno-tree-fre > it started with r11-4519-g53dede0f04bd95c3. Sorry I forgot to check with -fexception -fnon-call-exceptions for the older releases
[Bug rtl-optimization/105211] ICE: SIGSEGV in contains_struct_check (tree.h:3570) with -Os -ffast-math and __builtin_roundf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105211
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:91a38e8a848c61b2e23ee277306dc8cd194d135b
commit r12-8101-g91a38e8a848c61b2e23ee277306dc8cd194d135b
Author: Jakub Jelinek
Date: Tue Apr 12 09:16:06 2022 +0200
builtins: Fix up expand_builtin_int_roundingfn_2 [PR105211]
The expansion of __builtin_iround{,f,l} etc. builtins in some cases
emits calls to a different fallback builtin. To locate the right builtin
it uses mathfn_built_in_1 with the type of the first argument.
If its TYPE_MAIN_VARIANT is {float,double,long_double}_type_node, all is
fine, but on the following testcase, because GIMPLE considers scalar
float conversions between types with the same mode as useless,
TYPE_MAIN_VARIANT of the arg's type is float32_type_node and because there
isn't __builtin_lroundf32 returns NULL and we ICE.
This patch will first try the type of the first argument of the builtin's
prototype (so that say on sizeof(double)==sizeof(long double) target it
honors
whether it was a *l or non-*l call; though even that can't be 100% trusted,
user could incorrectly prototype it) and as fallback the type argument.
If neither works, doesn't fallback.
2022-04-11 Jakub Jelinek
PR rtl-optimization/105211
* builtins.cc (expand_builtin_int_roundingfn_2): If
mathfn_built_in_1
fails for TREE_TYPE (arg), retry it with
TREE_VALUE (TYPE_ARG_TYPES (TREE_TYPE (fndecl))) and if even that
fails, emit call normally.
* gcc.dg/pr105211.c: New test.
[Bug target/105214] [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105214 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d481d13786cb84f6294833538133dbd6f39d2e55 commit r12-8102-gd481d13786cb84f6294833538133dbd6f39d2e55 Author: Jakub Jelinek Date: Tue Apr 12 09:19:11 2022 +0200 i386: Fix ICE caused by ix86_emit_i387_log1p [PR105214] The following testcase ICEs, because ix86_emit_i387_log1p attempts to emit something like if (cond) some_code1; else some_code2; and emits a conditional jump using emit_jump_insn (standard way in the file) and an unconditional jump using emit_jump. The problem with that is that if there is pending stack adjustment, it isn't emitted before the conditional jump, but is before the unconditional jump and therefore stack is adjusted only conditionally (at the end of some_code1 above), which makes dwarf2 pass unhappy about it but is a serious wrong-code even if it doesn't ICE. This can be fixed either by emitting pending stack adjust before the conditional jump as the following patch does, or by not using emit_jump (label2); and instead hand inlining what that function does except for the pending stack adjustment, like: emit_jump_insn (targetm.gen_jump (label2)); emit_barrier (); In that case there will be no stack adjustment in the sequence and it will be done later on somewhere else. 2022-04-12 Jakub Jelinek PR target/105214 * config/i386/i386-expand.cc (ix86_emit_i387_log1p): Call do_pending_stack_adjust. * gcc.dg/asan/pr105214.c: New test.
[Bug sanitizer/105235] [11/12 Regression] ICE: in redirect_eh_edge_1, at tree-eh.cc:2323 with custom flags since r11-4519-g53dede0f04bd95c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105235 --- Comment #4 from Martin Liška --- (In reply to Zdenek Sojka from comment #3) > (In reply to Martin Liška from comment #2) > > With -c -O -fno-tree-dominator-opts -fnon-call-exceptions -fexceptions > > -fsanitize=thread -fno-tree-fre > > it started with r11-4519-g53dede0f04bd95c3. > > Sorry I forgot to check with -fexception -fnon-call-exceptions for the older > releases That's fine, I actually noticed that once I bisected that first time.
[Bug rtl-optimization/105211] ICE: SIGSEGV in contains_struct_check (tree.h:3570) with -Os -ffast-math and __builtin_roundf()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105211 --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/105214] [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105214 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug sanitizer/104449] [9/10 Regression] ICE: verify_gimple failed: dead statement in EH table with -fexceptions -fsanitize=address -fstack-check=generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104449 Bug 104449 depends on bug 105214, which changed state. Bug 105214 Summary: [12 Regression] ICE: in connect_traces, at dwarf2cfi.cc:3074 with custom flags https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105214 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/105226] [10/11/12 Regression] ICE in gimple_split_edge with -O3/fast and setjmp (returns twice)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105226 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2022-04-12 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug target/105215] IA64: ICE on openssl-1.1.1n in create_block_for_bookkeeping, at sel-sched.cc:4549 -O3 -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105215 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Last reconfirmed||2022-04-12 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Martin Liška --- Started with my r12-4608-gb4702276615ff8. I'll take a look..
[Bug tree-optimization/105226] [10/11/12 Regression] ICE in gimple_split_edge with -O3/fast and setjmp (returns twice) since r10-1057-g2778a719bebf7a32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105226 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | CC||marxin at gcc dot gnu.org Summary|[10/11/12 Regression] ICE |[10/11/12 Regression] ICE |in gimple_split_edge with |in gimple_split_edge with |-O3/fast and setjmp |-O3/fast and setjmp |(returns twice) |(returns twice) since ||r10-1057-g2778a719bebf7a32 --- Comment #2 from Martin Liška --- Started with r10-1057-g2778a719bebf7a32.
[Bug c++/105228] [9/10/11/12 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at cp/tree.cc:3826
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105228 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/105229] [11/12 Regression] ICE in lookup_template_class_1, at cp/pt.cc:10111
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105229 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug fortran/105230] [9/10/11/12 Regression] ICE in find_array_section, at fortran/expr.cc:1634
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105230 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.5
[Bug c++/105228] [9/10/11/12 Regression] ICE tree check: expected tree that contains 'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at cp/tree.cc:3826 since r7-755-g23cb72663051cd3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105228 Martin Liška changed: What|Removed |Added Summary|[9/10/11/12 Regression] ICE |[9/10/11/12 Regression] ICE |tree check: expected tree |tree check: expected tree |that contains 'decl |that contains 'decl |minimal' structure, have|minimal' structure, have |'error_mark' in |'error_mark' in |decl_anon_ns_mem_p, at |decl_anon_ns_mem_p, at |cp/tree.cc:3826 |cp/tree.cc:3826 since ||r7-755-g23cb72663051cd3f CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r7-755-g23cb72663051cd3f.
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 Richard Biener changed: What|Removed |Added CC||segher at gcc dot gnu.org Component|target |rtl-optimization Keywords||needs-bisection --- Comment #1 from Richard Biener --- As a quick guess combine eventually doesn't honor non-call EH and combines insns in a way that puts a trapping insn before another one. Could also be a x86 target specific pattern/splitter issue of course (not sure if passes are supposed to split blocks - a splitter definitely can't).
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-04-12 Summary|[12 Regression] ICE: in |[12 Regression] ICE: in |rtl_verify_bb_insns, at |rtl_verify_bb_insns, at |cfgrtl.cc:2797 (flow|cfgrtl.cc:2797 (flow |control insn inside a basic |control insn inside a basic |block) with custom flags|block) with custom flags ||since ||r12-4767-g81342e95827f77c0 Keywords|needs-bisection | --- Comment #2 from Martin Liška --- Started with r12-4767-g81342e95827f77c0.
[Bug tree-optimization/105232] [11/12 Regression] ICE in tree_to_poly_int64 via check_builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105232 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-04-12 --- Comment #1 from Martin Liška --- Started with r11-2928-gd14c547abd484d35.
[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P4
[Bug tree-optimization/105232] [11/12 Regression] ICE in tree_to_poly_int64 via check_builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105232 --- Comment #2 from Richard Biener --- Testing a patch.
[Bug tree-optimization/105232] [11/12 Regression] ICE in tree_to_poly_int64 via check_builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105232 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug c++/105236] failed lookup of alias with alias template of dependent template parameter containing lambda in unevaluated context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105236 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-04-12 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- This is rejected this way since r9-4045-g0c1e0d63fe0ceabbd04384070f3b59f8bf50de09 when P0315R4 has been implemented (before it emitted more errors).
[Bug sanitizer/105235] [11/12 Regression] ICE: in redirect_eh_edge_1, at tree-eh.cc:2323 with custom flags since r11-4519-g53dede0f04bd95c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105235
--- Comment #5 from Richard Biener ---
(In reply to Zdenek Sojka from comment #1)
> A slightly different testcase fails elsewhere:
>
> $ cat testcase.c
> int i, j;
>
> void
> foo (double d)
> {
> i = __builtin_ilogbl (d);
> j = __builtin_sinl (d);
> }
>
> $ x86_64-pc-linux-gnu-gcc -O -fno-tree-dominator-opts -fnon-call-exceptions
> -fsanitize=thread -fno-tree-fre testcase.c
> testcase.c: In function 'foo':
> testcase.c:4:1: error: BB 3 cannot throw but has an EH edge
> 4 | foo (double d)
> | ^~~
> during GIMPLE pass: sincos
> testcase.c:4:1: internal compiler error: verify_flow_info failed
> 0xe7c00e verify_flow_info()
> /repo/gcc-trunk/gcc/cfghooks.cc:284
> 0x128704a execute_function_todo
> /repo/gcc-trunk/gcc/passes.cc:2097
> 0x128755e execute_todo
> /repo/gcc-trunk/gcc/passes.cc:2139
> Please submit a full bug report, with preprocessed source (by using
> -freport-bug).
> Please include the complete backtrace with any bug report.
> See
[Bug sanitizer/105235] [11/12 Regression] ICE: in redirect_eh_edge_1, at tree-eh.cc:2323 with custom flags since r11-4519-g53dede0f04bd95c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105235 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |11.3
[Bug sanitizer/105235] [11/12 Regression] ICE: in redirect_eh_edge_1, at tree-eh.cc:2323 with custom flags since r11-4519-g53dede0f04bd95c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105235
--- Comment #6 from Jakub Jelinek ---
This has nothing to do with the sanitizers.
// PR tree-optimization/105235
// { dg-do compile }
// { dg-options "-O -fno-tree-dominator-opts -fexceptions -fnon-call-exceptions
-fno-tree-fre" }
struct S { ~S (); };
double
foo (double d)
{
S s;
return __builtin_ilogbl (d) + __builtin_sinl (d);
}
or
// PR tree-optimization/105235
// { dg-do compile }
// { dg-options "-O -fno-tree-dominator-opts -fexceptions -fnon-call-exceptions
-fno-tree-fre" }
struct T { ~T (); };
int i, j;
void
bar (double d)
{
T t;
i = __builtin_ilogbl (d);
j = __builtin_sinl (d);
}
ICE the same way.
[Bug tree-optimization/105235] [11/12 Regression] ICE: in redirect_eh_edge_1, at tree-eh.cc:2323 with custom flags since r11-4519-g53dede0f04bd95c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105235 --- Comment #7 from Richard Biener --- Also seems to fix the first testcase.
[Bug tree-optimization/105235] [11/12 Regression] ICE: in redirect_eh_edge_1, at tree-eh.cc:2323 with custom flags since r11-4519-g53dede0f04bd95c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105235 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #3 from Richard Biener ---
Before combine we had
(insn 22 17 78 3 (set (reg:SF 92)
(mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0 S4 A32]))
"t.c":6:3 142 {*movsf_internal}
(expr_list:REG_EQUAL (const_double:SF 1.8446744073709551616e+19
[0x0.8p+65])
(nil)))
(insn 78 22 24 3 (set (reg:XF 99)
(float_extend:XF (reg:SF 92))) 166 {*extendsfxf2_i387}
(expr_list:REG_DEAD (reg:SF 92)
(expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19
[0x0.8p+65])
(nil
(insn 24 78 65 3 (set (reg:XF 90)
(plus:XF (reg:XF 90)
(reg:XF 99))) "t.c":6:3 1070 {*fop_xf_comm_i387}
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)))
;; succ: 9 [never] count:0 (precise) (ABNORMAL,EH)
after:
(note 22 17 78 3 NOTE_INSN_DELETED)
(insn 78 22 24 3 (set (reg:XF 99)
(float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0
S4 A32]))) 166 {*extendsfxf2_i387}
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)))
(insn 24 78 26 3 (set (reg:XF 90)
(mem/u/c:XF (symbol_ref/u:SI ("*.LC3") [flags 0x2]) [0 S12 A128]))
"t.c":6:3 140 {*movxf_internal}
(nil))
(insn 26 24 27 3 (set (reg:DF 83 [ _2 ])
(float_truncate:DF (reg:XF 90))) "t.c":6:3 170 {truncxfdf2}
(expr_list:REG_DEAD (reg:XF 90)
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil
;; succ: 9 [never] count:0 (precise) (ABNORMAL,EH)
now sure where the REG_EH_REGION note on insn 78 comes from. I suppose it's
from
Trying 78, 17 -> 24:
78: r99:XF=float_extend([`*.LC0'])
REG_EQUAL 1.8446744073709551616e+19
17: r90:XF=[`*.LC1']
REG_EQUAL -1.444529636382101633e+18
24: r90:XF=r90:XF+r99:XF
REG_EH_REGION 0x1
...
Successfully matched this instruction:
(set (reg:XF 99)
(float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0 S4
A32])))
Successfully matched this instruction:
(set (reg:XF 90)
(mem/u/c:XF (symbol_ref/u:SI ("*.LC3") [flags 0x2]) [0 S12 A128]))
allowing combination of insns 17, 78 and 24
original costs 12 + 4 + 4 = 20
replacement costs 4 + 12 = 16
deferring deletion of insn with uid = 17.
modifying insn i278: r99:XF=float_extend([`*.LC0'])
REG_EH_REGION 0x1
deferring rescan insn with uid = 78.
modifying insn i324: r90:XF=[`*.LC3']
deferring rescan insn with uid = 24.
(removed failing matches)
So it does look like a combine problem to me which moves the EH note to
a random place. Also insn 26 still shows up from nowhere... (maybe that's
CFG cleanup).
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
Richard Biener changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #4 from Richard Biener ---
So interestingly distribute_notes sees
(gdb) p debug_rtx (i2)
(insn 78 22 24 3 (set (reg:XF 99)
(float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0
S4 A32]))) 166 {*extendsfxf2_i387}
(nil))
as may_trap_p (), but we did not place an EH note on this previously. I'm not
sure how the RTL IL is sanitized but eventually we simply take what RTL
expansion yields as granted.
Given combine doesn't split blocks (otherwise it would have "fixed" this),
it might make more sense to always put the note on i3 or drop it if i3
cannot trap?
Alternatively we can of course fail the combination if there's any EH note
and it's not (only) i3 that may_trap_p ().
diff --git a/gcc/combine.cc b/gcc/combine.cc
index 53dcac92abc..65e11c3e682 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -14185,8 +14185,8 @@ distribute_notes (rtx notes, rtx_insn *from_insn,
rtx_insn *i3, rtx_insn *i2,
gcc_assert (cfun->can_throw_non_call_exceptions);
if (may_trap_p (i3))
place = i3;
- else if (i2 && may_trap_p (i2))
- place = i2;
+ /* ??? Even if i2 may trap we cannot throw from there since
+it will be not last in the BB. Drop the EH in this case. */
/* ??? Otherwise assume we've combined things such that we
can now prove that the instructions can't trap. Drop the
note in this case. */
fixes the testcase (and loses the EH).
As said, I'm not sure about the EH state on RTL, insn_nothrow_p is false
on the original float_extent.
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 --- Comment #5 from Richard Biener --- may_trap_p triggers on the (float_extend:XF ...) because /* Any floating arithmetic may trap. */ if (FLOAT_MODE_P (GET_MODE (x)) && flag_trapping_math) return 1; with all that I think the proposed change is reasonable.
[Bug target/105234] inlining failed in call to 'always_inline' 'memset': target specific option mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234
--- Comment #4 from Martin Liška ---
Reduced test-case:
$ cat ~/Programming/testcases/AtomicFile.cpp.i
namespace std {
typedef char string;
class runtime_error {
public:
runtime_error(string);
};
} // namespace std
#pragma GCC push_options
namespace fmt {
namespace {
__attribute__((always_inline)) auto format() -> std::string {}
#pragma GCC pop_options
} // namespace
} // namespace fmt
namespace core {
class ErrorBase : std::runtime_error {
runtime_error::runtime_error;
};
class Error : ErrorBase {
public:
template Error(T &&...);
};
template Error::Error(T &&...) : ErrorBase(fmt::format()) {}
} // namespace core
void commit() { core::Error(); }
$ ./xg++ -B. ~/Programming/testcases/AtomicFile.cpp.i -c
/home/marxin/Programming/testcases/AtomicFile.cpp.i: In function ‘std::string
fmt::{anonymous}::format()’:
/home/marxin/Programming/testcases/AtomicFile.cpp.i:11:62: warning: no return
statement in function returning non-void [-Wreturn-type]
11 | __attribute__((always_inline)) auto format() -> std::string {}
| ^
/home/marxin/Programming/testcases/AtomicFile.cpp.i: At global scope:
/home/marxin/Programming/testcases/AtomicFile.cpp.i:17:3: warning: access
declarations are deprecated in favour of using-declarations; suggestion: add
the ‘using’ keyword [-Wdeprecated]
17 | runtime_error::runtime_error;
| ^
/home/marxin/Programming/testcases/AtomicFile.cpp.i:11:37: warning:
‘always_inline’ function might not be inlinable [-Wattributes]
11 | __attribute__((always_inline)) auto format() -> std::string {}
| ^~
/home/marxin/Programming/testcases/AtomicFile.cpp.i: In constructor
‘core::Error::Error(T&& ...) [with T = {}]’:
/home/marxin/Programming/testcases/AtomicFile.cpp.i:11:37: error: inlining
failed in call to ‘always_inline’ ‘std::string fmt::{anonymous}::format()’:
target specific option mismatch
/home/marxin/Programming/testcases/AtomicFile.cpp.i:23:73: note: called from
here
23 | template Error::Error(T &&...) :
ErrorBase(fmt::format()) {}
|
^
Note it crashes if I enable inlined dumps:
$ ./xg++ -B. ~/Programming/testcases/AtomicFile.cpp.i -c -fdump-tree-einline
/home/marxin/Programming/testcases/AtomicFile.cpp.i: In function ‘std::string
fmt::{anonymous}::format()’:
/home/marxin/Programming/testcases/AtomicFile.cpp.i:11:62: warning: no return
statement in function returning non-void [-Wreturn-type]
11 | __attribute__((always_inline)) auto format() -> std::string {}
| ^
/home/marxin/Programming/testcases/AtomicFile.cpp.i: At global scope:
/home/marxin/Programming/testcases/AtomicFile.cpp.i:17:3: warning: access
declarations are deprecated in favour of using-declarations; suggestion: add
the ‘using’ keyword [-Wdeprecated]
17 | runtime_error::runtime_error;
| ^
/home/marxin/Programming/testcases/AtomicFile.cpp.i:11:37: warning:
‘always_inline’ function might not be inlinable [-Wattributes]
11 | __attribute__((always_inline)) auto format() -> std::string {}
| ^~
during GIMPLE pass: einline
dump file: AtomicFile.cpp.i.031t.einline
/home/marxin/Programming/testcases/AtomicFile.cpp.i: In constructor
‘core::Error::Error(T&& ...) [with T = {}]’:
/home/marxin/Programming/testcases/AtomicFile.cpp.i:25:32: internal compiler
error: Segmentation fault
25 | void commit() { core::Error(); }
|^
0x183066f crash_signal
/home/marxin/Programming/gcc/gcc/toplev.cc:322
0x778b93cf ???
/usr/src/debug/glibc-2.35-2.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x1699c8c cl_target_option_print_diff(_IO_FILE*, int, cl_target_option*,
cl_target_option*)
/dev/shm/objdir2/gcc/options-save.cc:9319
0x262d142 report_inline_failed_reason
/home/marxin/Programming/gcc/gcc/ipa-inline.cc:249
0x262d6e4 can_inline_edge_p
/home/marxin/Programming/gcc/gcc/ipa-inline.cc:401
0x262eb19 can_early_inline_edge_p
/home/marxin/Programming/gcc/gcc/ipa-inline.cc:656
0x2635fac inline_always_inline_functions
/home/marxin/Programming/gcc/gcc/ipa-inline.cc:2866
0x2636516 early_inliner(function*)
/home/marxin/Programming/gcc/gcc/ipa-inline.cc:2976
0x263696f execute
/home/marxin/Programming/gcc/gcc/ipa-inline.cc:3110
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/105234] inlining failed in call to 'always_inline' 'memset': target specific option mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Last reconfirmed||2022-04-12 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/105226] [10/11/12 Regression] ICE in gimple_split_edge with -O3/fast and setjmp (returns twice) since r10-1057-g2778a719bebf7a32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105226 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:62d5bb0f35fb6ec373eaac942755585a633528a0 commit r12-8104-g62d5bb0f35fb6ec373eaac942755585a633528a0 Author: Richard Biener Date: Tue Apr 12 09:40:15 2022 +0200 tree-optimization/105226 - avoid splitting abnormal edges Vectorizer loop versioning tries to version outer loops if possible but fails to check whether it can actually split the single exit edge as it will do. 2022-04-12 Richard Biener PR tree-optimization/105226 * tree-vect-loop-manip.cc (vect_loop_versioning): Verify we can split the exit of an outer loop we choose to version. * gcc.dg/pr105226.c: New testcase.
[Bug tree-optimization/105232] [11/12 Regression] ICE in tree_to_poly_int64 via check_builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105232 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:1bd96873cf73c4f59de48e9bc0d17a498f1ede04 commit r12-8105-g1bd96873cf73c4f59de48e9bc0d17a498f1ede04 Author: Richard Biener Date: Tue Apr 12 09:54:32 2022 +0200 tree-optimization/105232 - handle overly large sizes in component_ref_size The following properly checks tree_fits_poly_int64_p before converting a size to a poly_int64. 2022-04-12 Richard Biener PR tree-optimization/105232 * tree.cc (component_ref_size): Bail out for too large or non-constant sizes.
[Bug tree-optimization/105226] [10/11 Regression] ICE in gimple_split_edge with -O3/fast and setjmp (returns twice) since r10-1057-g2778a719bebf7a32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105226 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Summary|[10/11/12 Regression] ICE |[10/11 Regression] ICE in |in gimple_split_edge with |gimple_split_edge with |-O3/fast and setjmp |-O3/fast and setjmp |(returns twice) since |(returns twice) since |r10-1057-g2778a719bebf7a32 |r10-1057-g2778a719bebf7a32 Known to work||12.0
[Bug tree-optimization/105232] [11 Regression] ICE in tree_to_poly_int64 via check_builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105232 Richard Biener changed: What|Removed |Added Summary|[11/12 Regression] ICE in |[11 Regression] ICE in |tree_to_poly_int64 via |tree_to_poly_int64 via |check_builtin |check_builtin Known to work||12.0 Priority|P3 |P2
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #6 from Eric Botcazou ---
> So interestingly distribute_notes sees
>
> (gdb) p debug_rtx (i2)
> (insn 78 22 24 3 (set (reg:XF 99)
> (float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2])
> [0 S4 A32]))) 166 {*extendsfxf2_i387}
> (nil))
>
> as may_trap_p (), but we did not place an EH note on this previously. I'm
> not sure how the RTL IL is sanitized but eventually we simply take what RTL
> expansion yields as granted.
This is the insn before combine though:
(insn 78 22 24 3 (set (reg:XF 99)
(float_extend:XF (reg:SF 92))) 166 {*extendsfxf2_i387}
(expr_list:REG_DEAD (reg:SF 92)
(expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19
[0x0.8p+65])
(nil
so combine apparently forced the constant into the constant pool.
[Bug c++/94061] defaulted member operator <=> defined as deleted if a base has protected member operator <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94061
--- Comment #4 from Baudouin Feildel
---
We also ran into this issue with operator==(). This behavior might be explained
by some implementation detail of the generated code for the operator, but we
believe it is wrong because it is inconsistent, see the following example
(https://godbolt.org/z/f4EjojExh):
struct Base {
protected:
Base() = default;
bool operator==(const Base& other) const = default;
};
struct Child : Base {
int i = 0;
Child() = default;
bool operator==(const Child& other) const = default;
};
int main()
{
Child a1;
Child b1;
return a1 == b1;
}
Here calling protected constructor in defaulted ctor is totally fine. But
trying to do the same with comparison operator fails with the following
compiler error:
: In function 'int main()':
:17:18: error: use of deleted function 'constexpr bool
Child::operator==(const Child&) const'
17 | return a1 == b1;
| ^~
:10:10: note: 'constexpr bool Child::operator==(const Child&) const' is
implicitly deleted because the default definition would be ill-formed:
10 | bool operator==(const Child& other) const = default;
| ^~~~
:10:10: error: 'bool Base::operator==(const Base&) const' is protected
within this context
:4:10: note: declared protected here
4 | bool operator==(const Base& other) const = default;
| ^~~~
This behavior is unfortunate and make it very difficult to use defaulted
operator== when you have a common base class that should not be comparable. See
this other example: https://godbolt.org/z/v78r1nYr9.
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #7 from rguenther at suse dot de ---
On Tue, 12 Apr 2022, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
>
> --- Comment #6 from Eric Botcazou ---
> > So interestingly distribute_notes sees
> >
> > (gdb) p debug_rtx (i2)
> > (insn 78 22 24 3 (set (reg:XF 99)
> > (float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2])
> > [0 S4 A32]))) 166 {*extendsfxf2_i387}
> > (nil))
> >
> > as may_trap_p (), but we did not place an EH note on this previously. I'm
> > not sure how the RTL IL is sanitized but eventually we simply take what RTL
> > expansion yields as granted.
>
> This is the insn before combine though:
>
> (insn 78 22 24 3 (set (reg:XF 99)
> (float_extend:XF (reg:SF 92))) 166 {*extendsfxf2_i387}
> (expr_list:REG_DEAD (reg:SF 92)
> (expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19
> [0x0.8p+65])
> (nil
>
> so combine apparently forced the constant into the constant pool.
Yes, but still the float_extend:XF would have made may_trap_p say
the insn possibly traps but there's no EH on it despite
-fnon-call-exceptions.
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #8 from Eric Botcazou ---
> Yes, but still the float_extend:XF would have made may_trap_p say
> the insn possibly traps but there's no EH on it despite
> -fnon-call-exceptions.
The REG_EH note is added by make_reg_eh_region_note but then removed by
purge_dead_edges because of the REG_EQUAL note:
/* If this instruction cannot trap, remove REG_EH_REGION notes. */
if (NONJUMP_INSN_P (insn)
&& (note = find_reg_note (insn, REG_EH_REGION, NULL)))
{
rtx eqnote;
if (! may_trap_p (PATTERN (insn))
|| ((eqnote = find_reg_equal_equiv_note (insn))
&& ! may_trap_p (XEXP (eqnote, 0
remove_note (insn, note);
}
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 --- Comment #9 from Richard Biener --- Initially we generate (insn 36 35 37 (set (reg:XF 95) (float_extend:XF (reg:SF 96))) "t.c":6:3 -1 (expr_list:REG_EH_REGION (const_int 1 [0x1]) (expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19 [0x0.8p+65]) (nil (insn 37 36 38 (set (reg:XF 94) (plus:XF (reg:XF 94) (reg:XF 95))) "t.c":6:3 -1 (expr_list:REG_EH_REGION (const_int 1 [0x1]) (nil))) but then when creating BBs we end up with (insn 36 35 37 12 (set (reg:XF 95) (float_extend:XF (reg:SF 96))) "t.c":6:3 -1 (expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19 [0x0.8p+65]) (nil))) (insn 37 36 38 12 (set (reg:XF 94) (plus:XF (reg:XF 94) (reg:XF 95))) "t.c":6:3 -1 (expr_list:REG_EH_REGION (const_int 1 [0x1]) (nil))) ;; succ: 17 [never] count:0 (precise) (ABNORMAL,EH) so it seems we retain the GIMPLE BB structure which just had _3 = (double) 18446744073709551614; ;;succ: 7 ;;5 rather than splitting the EH into the now two possibly throwing stmts? Maybe it's also specially handled because of the REG_EQUAL note? At least find_many_sub_basic_blocks via control_flow_insn_p doesn't consider insns with a REG_EH_REGION note as ending a BB but it only checks can_throw_internal which may or may not be enough here.
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #10 from Richard Biener ---
(In reply to Eric Botcazou from comment #8)
> > Yes, but still the float_extend:XF would have made may_trap_p say
> > the insn possibly traps but there's no EH on it despite
> > -fnon-call-exceptions.
>
> The REG_EH note is added by make_reg_eh_region_note but then removed by
> purge_dead_edges because of the REG_EQUAL note:
>
> /* If this instruction cannot trap, remove REG_EH_REGION notes. */
> if (NONJUMP_INSN_P (insn)
> && (note = find_reg_note (insn, REG_EH_REGION, NULL)))
> {
> rtx eqnote;
>
> if (! may_trap_p (PATTERN (insn))
> || ((eqnote = find_reg_equal_equiv_note (insn))
> && ! may_trap_p (XEXP (eqnote, 0
> remove_note (insn, note);
> }
Interesting - so should combine maybe have this exception as well when it
tests for may_trap_p? Not sure if the above makes sense.
[Bug target/104144] [12 Regression] build fails due to: Error: unknown architecture `armv9-a'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104144 --- Comment #9 from CVS Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:1210fd6e69e51516c935acc49e223fce14a0dd86 commit r12-8106-g1210fd6e69e51516c935acc49e223fce14a0dd86 Author: Przemyslaw Wirkus Date: Mon Apr 11 13:14:01 2022 +0100 arm: remove unnecessary armv9-a multilib variant [PR104144] Remove the armv9-a specific multilib variants. Instead, arrange to use either the armv8-a multilibs or the armv7-a versions, depeding on the configuration. This eliminates the need to have a version of gas that understands --march=armv9-a when building GCC. Very little, if anything in the standard libraries directly uses Armv9-a features anyway. Also remove the +crc variant rules for Armv9-a. CRC is an implicit part of Armv9-a, so doesn't have a explicit feature to handle it. gcc/ChangeLog: PR target/104144 * config/arm/t-aprofile (MULTI_ARCH_OPTS_A): Remove Armv9-a options. (MULTI_ARCH_DIRS_A): Remove Armv9-a diretories. (MULTILIB_REQUIRED): Don't require Armv9-a libraries. (MULTILIB_MATCHES): Treat Armv9-a as equivalent to Armv8-a. (MULTILIB_REUSE): Remove remap rules for Armv9-a. * config/arm/t-multilib (v9_a_nosimd_variants): Delete. (MULTILIB_MATCHES): Remove mappings for v9_a_nosimd_variants. gcc/testsuite/ChangeLog: PR target/104144 * gcc.target/arm/multilib.exp: Updated tests.
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #11 from Richard Biener ---
(In reply to Richard Biener from comment #10)
> (In reply to Eric Botcazou from comment #8)
> > > Yes, but still the float_extend:XF would have made may_trap_p say
> > > the insn possibly traps but there's no EH on it despite
> > > -fnon-call-exceptions.
> >
> > The REG_EH note is added by make_reg_eh_region_note but then removed by
> > purge_dead_edges because of the REG_EQUAL note:
> >
> > /* If this instruction cannot trap, remove REG_EH_REGION notes. */
> > if (NONJUMP_INSN_P (insn)
> > && (note = find_reg_note (insn, REG_EH_REGION, NULL)))
> > {
> > rtx eqnote;
> >
> > if (! may_trap_p (PATTERN (insn))
> > || ((eqnote = find_reg_equal_equiv_note (insn))
> > && ! may_trap_p (XEXP (eqnote, 0
> > remove_note (insn, note);
> > }
>
> Interesting - so should combine maybe have this exception as well when it
> tests for may_trap_p? Not sure if the above makes sense.
That code was added by Jakub in r0-38443-g89753b3a903366, reverting the
reg-equal note part fixes the testcase as well.
[Bug target/105234] [12 Regression] inlining failed in call to 'always_inline' 'memset': target specific option mismatch since r12-5920-g01ad8c54fdca1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234 Martin Liška changed: What|Removed |Added CC||linkw at gcc dot gnu.org Summary|inlining failed in call to |[12 Regression] inlining |'always_inline' 'memset': |failed in call to |target specific option |'always_inline' 'memset': |mismatch|target specific option ||mismatch since ||r12-5920-g01ad8c54fdca1d Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #5 from Martin Liška --- Started with r12-5920-g01ad8c54fdca1d.
[Bug target/104144] [12 Regression] build fails due to: Error: unknown architecture `armv9-a'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104144 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Richard Earnshaw --- Fixed, by adjusting the selection of multilibs that are needed. There's no benefit to building armv9-a multilibs, so use those built for armv8-a.
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #12 from Richard Biener ---
(In reply to Richard Biener from comment #11)
> (In reply to Richard Biener from comment #10)
> > (In reply to Eric Botcazou from comment #8)
> > > > Yes, but still the float_extend:XF would have made may_trap_p say
> > > > the insn possibly traps but there's no EH on it despite
> > > > -fnon-call-exceptions.
> > >
> > > The REG_EH note is added by make_reg_eh_region_note but then removed by
> > > purge_dead_edges because of the REG_EQUAL note:
> > >
> > > /* If this instruction cannot trap, remove REG_EH_REGION notes. */
> > > if (NONJUMP_INSN_P (insn)
> > > && (note = find_reg_note (insn, REG_EH_REGION, NULL)))
> > > {
> > > rtx eqnote;
> > >
> > > if (! may_trap_p (PATTERN (insn))
> > > || ((eqnote = find_reg_equal_equiv_note (insn))
> > > && ! may_trap_p (XEXP (eqnote, 0
> > > remove_note (insn, note);
> > > }
> >
> > Interesting - so should combine maybe have this exception as well when it
> > tests for may_trap_p? Not sure if the above makes sense.
>
> That code was added by Jakub in r0-38443-g89753b3a903366, reverting the
> reg-equal note part fixes the testcase as well.
Oh, and checking for REG_EQUAL notes on i2/i3 doesn't work since they do not
exist there. Likewise REG_EQUAL notes can be simply dropped which would
make the IL "invalid" so I think what purge_dead_edges does is premature?
[Bug tree-optimization/105235] [11/12 Regression] ICE: in redirect_eh_edge_1, at tree-eh.cc:2323 with custom flags since r11-4519-g53dede0f04bd95c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105235 --- Comment #8 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:31cccadcf2d3cc8acb7a5f36ed57ca847f7ea0ea commit r12-8107-g31cccadcf2d3cc8acb7a5f36ed57ca847f7ea0ea Author: Richard Biener Date: Tue Apr 12 10:07:10 2022 +0200 tree-optimization/105235 - clean EH in execute_cse_conv_1 When a FP conversion is removed we have to eventually clean EH. 2022-04-12 Richard Biener PR tree-optimization/105235 * tree-ssa-math-opts.cc (execute_cse_conv_1): Clean EH and return whether the CFG changed. (execute_cse_sincos_1): Adjust. * g++.dg/opt/pr105235-1.C: New testcase.
[Bug tree-optimization/105237] New: Missing uninitialized warning in self-initialization case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105237
Bug ID: 105237
Summary: Missing uninitialized warning in self-initialization
case
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nojus.gudinavicius at gmail dot com
Target Milestone: ---
Created attachment 52789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52789&action=edit
Reproducer source code
Sorry if this is a dup of bug 18501. The other samples seemed to follow
different pattern than mine so I decided to post separately. Anyway:
$ cat t.c
#include
#include
int negate(int n) { return -n; }
void doexit() { exit(0); }
void test() {
int n;
while ((n=1) > 0) {
int n = negate(n); // n used before initialization
printf("%d\n", n);
doexit();
}
}
int main() {
test();
}
$ gcc -Wall t.c # no warning. replacing doexit call with break shows the
warning
Without the function call the reproducer is smaller, although maybe less likely
to be run into:
int n;
{
int n = n;
printf("%d\n", n);
}
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 --- Comment #13 from Eric Botcazou --- > Oh, and checking for REG_EQUAL notes on i2/i3 doesn't work since they do not > exist there. Likewise REG_EQUAL notes can be simply dropped which would > make the IL "invalid" so I think what purge_dead_edges does is premature? Everything is consistent until combine messes things up, so I'd rather find a fix/kludge in combine if possible. Penalizing everyone because of an artificial testcase exercising a nonsensical set of options is IMO not the way to go.
[Bug tree-optimization/105237] Missing uninitialized warning in self-initialization case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105237
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-04-12
Blocks||24639
--- Comment #1 from Richard Biener ---
If you enable optimization (inlining in this case) the warning is shown:
> gcc-11 -S t2.c -Wall -O
t2.c: In function 'test':
t2.c:2:28: warning: 'n' is used uninitialized [-Wuninitialized]
2 | int negate(int n) { return -n; }
|^~
t2.c:8:13: note: 'n' was declared here
8 | int n = negate(n); // n used before initialization
| ^
without optimization we are confused by the loop and limited flow analysis.
The
int n = n;
case is a GCC extension to silence uninit diagnostics
Confirmed at -O0.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 --- Comment #14 from rguenther at suse dot de --- On Tue, 12 Apr 2022, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 > > --- Comment #13 from Eric Botcazou --- > > Oh, and checking for REG_EQUAL notes on i2/i3 doesn't work since they do not > > exist there. Likewise REG_EQUAL notes can be simply dropped which would > > make the IL "invalid" so I think what purge_dead_edges does is premature? > > Everything is consistent until combine messes things up, so I'd rather find a > fix/kludge in combine if possible. Penalizing everyone because of an > artificial testcase exercising a nonsensical set of options is IMO not the way > to go. So my original patch still works - since combine doesn't split the block, transfering EH edges, when it moves the note to i2 it should simply never do that but instead drop it on the floor. Which of course is a kludge and possibly wrong-code. Alternatively we could mark as non-trapping (insn 36 35 37 (set (reg:XF 95) (float_extend:XF (reg:SF 96))) "t.c":6:3 -1 (expr_list:REG_EH_REGION (const_int 1 [0x1]) (expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19 [0x0.8p+65]) (nil at the point we remove the REG_EH_REGION note because of the REG_EQUAL note? Because we know it won't trap.
[Bug tree-optimization/105237] Missing uninitialized warning in self-initialization case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105237 --- Comment #2 from Andrew Pinski --- Note: int n = n; Is a documented way of having the uninitiated warning to not happen.
[Bug target/105234] [12 Regression] inlining failed in call to 'always_inline' 'memset': target specific option mismatch since r12-5920-g01ad8c54fdca1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- >From what I can see, push_options creates a new target node because there wasn't one before, pop_options makes that the current node and the mismatch is in between that node (containing just the mips_lra_flag set, which is the default) and NULL. I think the main problem is that mips doesn't initialize target_option_default_node.
[Bug target/105234] [12 Regression] inlining failed in call to 'always_inline' 'memset': target specific option mismatch since r12-5920-g01ad8c54fdca1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |12.0
[Bug target/105234] [12 Regression] inlining failed in call to 'always_inline' 'memset': target specific option mismatch since r12-5920-g01ad8c54fdca1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234 --- Comment #7 from Jakub Jelinek --- On the other side, most of the targets actually don't initialize target_option_default_node. List of targets that do so: aarch64/aarch64.cc: target_option_default_node = target_option_current_node arm/arm.cc: target_option_default_node = target_option_current_node csky/csky.cc: target_option_default_node = target_option_current_node i386/i386-options.cc: target_option_default_node = target_option_current_node nios2/nios2.cc: target_option_default_node = target_option_current_node pru/pru.cc: target_option_default_node = target_option_current_node rs6000/rs6000.cc:target_option_default_node = target_option_current_node s390/s390.cc: target_option_default_node = build_target_option_node (&global_options, &global_options_set); v850/v850.cc: target_option_default_node = target_option_current_node and list of targets that actually support target attribute: aarch64/aarch64.cc:#define TARGET_OPTION_VALID_ATTRIBUTE_P aarch64_option_valid_attribute_p arm/arm.cc:#define TARGET_OPTION_VALID_ATTRIBUTE_P arm_valid_target_attribute_p i386/i386.cc:#define TARGET_OPTION_VALID_ATTRIBUTE_P ix86_valid_target_attribute_p nios2/nios2.cc:#define TARGET_OPTION_VALID_ATTRIBUTE_P nios2_valid_target_attribute_p rs6000/rs6000.cc:#define TARGET_OPTION_VALID_ATTRIBUTE_P rs6000_valid_attribute_p s390/s390.cc:#define TARGET_OPTION_VALID_ATTRIBUTE_P s390_valid_target_attribute_p So perhaps the generic r12-5920 change should be guarded on target_option_default_node being non-NULL, so that targets that don't care can stay as is? The question is what to do with csky, pru and v850 that initialize it but don't support target attributes?
[Bug target/105234] [12 Regression] inlining failed in call to 'always_inline' 'memset': target specific option mismatch since r12-5920-g01ad8c54fdca1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234
--- Comment #8 from Jonathan Wakely ---
(In reply to Martin Liška from comment #4)
> Reduced test-case:
Slightly less reduced, avoiding the warnings about invalid/deprecated features:
namespace std {
typedef char string;
class runtime_error {
public:
runtime_error(string);
};
} // namespace std
#pragma GCC push_options
namespace fmt {
namespace {
__attribute__((always_inline)) inline auto format() -> std::string { return {};
}
#pragma GCC pop_options
} // namespace
} // namespace fmt
namespace core {
class ErrorBase : std::runtime_error {
using runtime_error::runtime_error;
};
class Error : ErrorBase {
public:
template Error(T &&...);
};
template Error::Error(T &&...) : ErrorBase(fmt::format()) {}
} // namespace core
void commit() { core::Error(); }
[Bug tree-optimization/105226] [10/11 Regression] ICE in gimple_split_edge with -O3/fast and setjmp (returns twice) since r10-1057-g2778a719bebf7a32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105226 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:249aa9348ddf06b8961a3418c74e6d83963cdc1e commit r11-9812-g249aa9348ddf06b8961a3418c74e6d83963cdc1e Author: Richard Biener Date: Tue Apr 12 09:40:15 2022 +0200 tree-optimization/105226 - avoid splitting abnormal edges Vectorizer loop versioning tries to version outer loops if possible but fails to check whether it can actually split the single exit edge as it will do. 2022-04-12 Richard Biener PR tree-optimization/105226 * tree-vect-loop-manip.c (vect_loop_versioning): Verify we can split the exit of an outer loop we choose to version. * gcc.dg/pr105226.c: New testcase. (cherry picked from commit 62d5bb0f35fb6ec373eaac942755585a633528a0)
[Bug tree-optimization/105232] [11 Regression] ICE in tree_to_poly_int64 via check_builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105232 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:008d568ac7eba4057172c52d306e09d174041c59 commit r11-9813-g008d568ac7eba4057172c52d306e09d174041c59 Author: Richard Biener Date: Tue Apr 12 09:54:32 2022 +0200 tree-optimization/105232 - handle overly large sizes in component_ref_size The following properly checks tree_fits_poly_int64_p before converting a size to a poly_int64. 2022-04-12 Richard Biener PR tree-optimization/105232 * tree.c (component_ref_size): Bail out for too large or non-constant sizes. (cherry picked from commit 1bd96873cf73c4f59de48e9bc0d17a498f1ede04)
[Bug tree-optimization/105235] [11 Regression] ICE: in redirect_eh_edge_1, at tree-eh.cc:2323 with custom flags since r11-4519-g53dede0f04bd95c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105235 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Richard Biener : https://gcc.gnu.org/g:28ef9276654856b53ba45f0082e6579c365e2962 commit r11-9814-g28ef9276654856b53ba45f0082e6579c365e2962 Author: Richard Biener Date: Tue Apr 12 10:07:10 2022 +0200 tree-optimization/105235 - clean EH in execute_cse_conv_1 When a FP conversion is removed we have to eventually clean EH. 2022-04-12 Richard Biener PR tree-optimization/105235 * tree-ssa-math-opts.c (execute_cse_conv_1): Clean EH and return whether the CFG changed. (execute_cse_sincos_1): Adjust. * g++.dg/opt/pr105235-1.C: New testcase. (cherry picked from commit 31cccadcf2d3cc8acb7a5f36ed57ca847f7ea0ea)
[Bug tree-optimization/105235] [11 Regression] ICE: in redirect_eh_edge_1, at tree-eh.cc:2323 with custom flags since r11-4519-g53dede0f04bd95c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105235 Richard Biener changed: What|Removed |Added Known to work||11.2.1 Known to fail||11.2.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Richard Biener --- Fixed.
[Bug tree-optimization/105232] [11 Regression] ICE in tree_to_poly_int64 via check_builtin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105232 Richard Biener changed: What|Removed |Added Known to fail||11.2.0 Status|ASSIGNED|RESOLVED Known to work||11.2.1 Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug ipa/103818] [12 Regression] ICE: in insert, at ipa-modref-tree.c:591 since r12-3202-gf5ff3a8ed4ca9173
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103818
--- Comment #6 from hubicka at kam dot mff.cuni.cz ---
> For 128-bit math, you can e.g. use poly_offset_int, which generally looks like
> a better type for these offsets and sizes (especially if they are counted in
> bits not bytes).
> Just to perform the <= comparison on the wider poly_offset_int, perhaps:
> --- gcc/ipa-modref-tree.cc.jj 2022-04-06 16:44:44.0 +0200
> +++ gcc/ipa-modref-tree.cc 2022-04-11 17:50:02.937784764 +0200
> @@ -380,9 +380,13 @@ modref_access_node::update2 (poly_int64
> new_max_size = max_size2;
>else
> {
> - new_max_size = max_size2 + offset2 - offset1;
> - if (known_le (new_max_size, max_size1))
> + poly_offset_int n = max_size2;
> + n += offset2;
> + n -= offset1;
> + if (known_le (n, max_size1))
> new_max_size = max_size1;
> + else
> + new_max_size = max_size2 + offset2 - offset1;
> }
>
>update (parm_offset1, offset1,
> (though, not sure how can you narrow that back to poly_int64).
> Though, the big question is what should one do with these overflows or
> underflows that aren't representable, update2 can't fail right now and the
> above still ICEs.
> Is there some way how to indicate it is an access to an unknown offset?
I sent patch for this (and plan to commit it today). One can set new_max_size
to -1 which means unknown/unlimited rnag on overflow. Underflow should
be impossible, since we always keep offsets/sizes nonnegative.
Honza
[Bug ipa/105227] [9/10/11/12 Regression] ICE in type_in_anonymous_namespace_p, at ipa-utils.h:233 since r9-2502-g143b379d89b12ccc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105227 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #3 from Jan Hubicka --- mine.
[Bug target/105234] [12 Regression] inlining failed in call to 'always_inline' 'memset': target specific option mismatch since r12-5920-g01ad8c54fdca1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #9 from Martin Liška --- I can take a look.
[Bug target/105234] [12 Regression] inlining failed in call to 'always_inline' 'memset': target specific option mismatch since r12-5920-g01ad8c54fdca1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234
--- Comment #10 from Jakub Jelinek ---
2022-04-12 Jakub Jelinek
PR target/105234
* attribs.cc (decl_attributes): Don't set
DECL_FUNCTION_SPECIFIC_TARGET if target_option_default_node is
NULL.
--- gcc/attribs.cc.jj 2022-02-04 14:36:53.947620076 +0100
+++ gcc/attribs.cc 2022-04-12 12:52:36.630967329 +0200
@@ -636,15 +636,20 @@ decl_attributes (tree *node, tree attrib
&& !DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node))
{
DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node) = optimization_current_node;
- tree cur_tree
- = build_target_option_node (&global_options, &global_options_set);
- tree old_tree = DECL_FUNCTION_SPECIFIC_TARGET (*node);
- if (!old_tree)
- old_tree = target_option_default_node;
- /* The changes on optimization options can cause the changes in
-target options, update it accordingly if it's changed. */
- if (old_tree != cur_tree)
- DECL_FUNCTION_SPECIFIC_TARGET (*node) = cur_tree;
+ /* Don't set DECL_FUNCTION_SPECIFIC_TARGET for targets that don't
+support #pragma GCC target or target attribute. */
+ if (target_option_default_node)
+ {
+ tree cur_tree
+ = build_target_option_node (&global_options, &global_options_set);
+ tree old_tree = DECL_FUNCTION_SPECIFIC_TARGET (*node);
+ if (!old_tree)
+ old_tree = target_option_default_node;
+ /* The changes on optimization options can cause the changes in
+target options, update it accordingly if it's changed. */
+ if (old_tree != cur_tree)
+ DECL_FUNCTION_SPECIFIC_TARGET (*node) = cur_tree;
+ }
}
/* If this is a function and the user used #pragma GCC target, add the
certainly works for me.
[Bug target/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219 --- Comment #5 from Tamar Christina --- OK, I think this is an alignment issue. When using the thunderx cost model it needs to peel the loop for alignment in order to vectorize and it looks the error is there.
[Bug target/105234] [12 Regression] inlining failed in call to 'always_inline' 'memset': target specific option mismatch since r12-5920-g01ad8c54fdca1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234 --- Comment #11 from Jakub Jelinek --- Created attachment 52790 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52790&action=edit gcc12-pr105234.patch Now with a testcase.
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 --- Comment #15 from Richard Biener --- But looking at all the distribute_notes calls I'm not sure that i2 and i3 are passed in execution order or that i3 is always the last instruction in the set of insns that are combined?
[Bug target/105234] [12 Regression] inlining failed in call to 'always_inline' 'memset': target specific option mismatch since r12-5920-g01ad8c54fdca1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105234 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #12 from Martin Liška --- The patch seems fine to me.
[Bug tree-optimization/105217] Likely wrong code with -D_FORTIFY_SOURCE=3 since r12-6482-g06bc1b0c539e3a60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105217
Siddhesh Poyarekar changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Siddhesh Poyarekar ---
Here's a simplified version that shows the problem:
typedef __SIZE_TYPE__ size_t;
#define OLD 40
#define NEW 80
#define OFF 10
int
main (void)
{
char *p = __builtin_malloc (OLD);
char *q = 0;
char *dst = p + OFF;
q = __builtin_realloc (p, NEW);
if (q == 0)
__builtin_unreachable ();
if (q != p)
{
p = q;
dst = q + OFF;
}
__builtin_printf ("old size: %zu, new size: %zu, __bdos: %zu\n",
OLD - OFF, NEW - OFF,
__builtin_dynamic_object_size (dst, 0));
}
The problem is when realloc does not result in a different buffer (q == p);
`dst` is left untouched assuming that it's the same object. I doubt if this is
a portable assumption, since the C standard says that value of q (and
consequently dst?) will have become invalid beyond its lifetime, i.e. the
moment it is realloc'd:
6.2.4 Storage durations of objects
...
The value of a pointer becomes indeterminate when the object it points to (or
just past) reaches the end of its lifetime.
...
It just happens so that with the glibc malloc implementation it remains valid
but ISTM that applications should not rely on it.
Jakub, would you concur with this?
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 --- Comment #16 from Jakub Jelinek --- i3 is always the last, that is the ultimate insn into which the other insns are combined into.
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #17 from Jakub Jelinek ---
For the testcase, again no reason for -fsanitize=thread,
void baz (int *);
void bar (double, double, _Decimal64);
void
foo (void)
{
int s __attribute__((cleanup (baz)));
bar (0xfffe, 0xebf3fff2fbebaf7f, 0xff);
}
will ICE even with just
-Os -fsanitize-coverage=trace-pc -fnon-call-exceptions --param=max-cse-insns=1
-frounding-math -mstack-arg-probe -m32
[Bug target/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219 --- Comment #6 from Richard Biener --- eventually you can narrow down the mis-vectorized loop with -fdbg-cnt=vect_loop:1-1 vs 2-2 (and the 2nd loop has its epilogue vectorized for me? so maybe try with --param vect-epilogues-nomask=0 as well.
[Bug gcov-profile/105238] New: Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 Bug ID: 105238 Summary: Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken Product: gcc Version: 9.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: esgergn at hotmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Gist: - gcc 9 / 10 (and later?) gcno files are not ccache cachable anymore because of the absolute CWD path they contain - when using -fprofile-dir with gcc 9 and 10 gcovr is not able to produce correct reports where it can do so when not using -fprofile-dir. Situation: CMake project with multiple subprojects with the following structure (condensed) /home/esger/src/ application/ CMakeLists.txt source/ staticlibA/ CMakeLists.txt source/ A.cpp staticlibB/ CMakeLists.txt source/ B.cpp main.cpp test/ CMakeLists.txt source/ test_main.cpp We are building, with coverage, from different directories with often only minor code changes between directories, therefore ccache is able to provide a very significant speedup. When using ccache 4.5.1 (with a small bug fix, see https://github.com/ccache/ccache/issues/1032) and gcc 7.5.0 this works perfectly. When compiling for instance B.cpp we use flags: -fprofile-dir=./build/source/staticlibB/CMakeFiles/staticlibB.dir/source -fdebug-prefix-map=/home/esger/src/application=. and CCACHE_BASEDIR=/home/esger/src/application (this rewrites the absolute paths CMake uses to relative paths starting at the base dir. Ie. /home/esger/src/application/build/source/staticlibB/CMakeFiles/staticlibB.dir/source/B.cpp becomes ./build/source/staticlibB/CMakeFiles/staticlibB.dir/source/B.cpp) with /home/esger/src/application/build/source/staticlibB/CMakeFiles/staticlibB.dir/source as cwd for the compilation of B.cpp. This produces .o and .gcno files containing relative paths that can be cached by ccache. When running ./build/bin/test_main from /home/esger/src/application gcda files are created next to the gcno files. When compiling a second time from a new directory /home/esger/src/application-2, the .o and .gcno are taken from the cache and when running ./build/bin/test_main from /home/esger/src/application-2 again gcda are created next to the .gcno files below application-2. Gcovr produces an identical coverage report for both dirs. So far so good ;) When switching to gcc 9.3 however this does not work anymore and the coverage reports are empty (even on builds were the cache was empty and no cached .o/gcno's were used). I found https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97193 about incorrect mangling of gcno files so tried gcc 9.4 as well which still does not work. It seems the behavior of -fprofile-dir has changed according to the documentation: "-fprofile-dir=path Set the directory to search for the profile data files in to path. This option affects only the profile data generated by -fprofile-generate, -ftest-coverage, -fprofile-arcs and used by -fprofile-use and -fbranch-probabilities and its related options. Both absolute and relative paths can be used. By default, GCC uses the current directory as path, thus the profile data file appears in the same directory as the object file. In order to prevent the file name clashing, if the object file name is not an absolute path, we mangle the absolute path of the sourcename.gcda file and use it as the file name of a .gcda file." Note that the latter part where the absolute path of the source is mangled and used as the file name is not helpful in our use case. We absolutely want a relative path when specifying a relative path to -fprofile-dir and have no absolute paths anywhere. I am certain in some cases there can be file name clashing, but as far as I am aware that is not a problem at all in our use case. (so it would be nice if this behavior at least can be turned off) Added to that in 9.4 there seem to be more problems with -fprofile-dir? Given a trivial main.cpp: cwd = /home/esger/src/application/coverage_test/dir1/source $ g++ --coverage main.cpp $ ls a.out main.cpp main.gcno $ ./a.out $ ls a.out main.cpp main.gcda main.gcno $ gcovr --html -o coverage.html . [coverage report OK] $ g++ --coverage -fprofile-dir=. main.cpp $ ls a.out main.cpp main.gcno $ ./a.out $ ls '#home#esger#src#application#coverage_test#dir1#source#main.gcda' a.out main.cpp main.gcno $ gcovr --html -o coverage.html . [coverage report broken, shows main.cpp but with 0% coverage] $ g++ --coverage -fprofile-dir=/home/esger/src/application/coverage_test/dir1/source main.cpp $ ls a.out main.cpp mai
[Bug target/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219 --- Comment #7 from Tamar Christina --- I have managed to find the commit where this starts failing: commit 61fc5e098e76c9809f35f449a70c9c8d74773d9d (HEAD) Author: Richard Biener Date: Fri Feb 18 11:34:52 2022 +0100 tree-optimization/104582 - Simplify vectorizer cost API and fixes This simplifies the vectorizer cost API by providing overloads to add_stmt_cost and record_stmt_cost suitable for scalar stmt and branch stmt costing which do not need information like a vector type or alignment. It also fixes two mistakes where costs for versioning tests were recorded as vector stmt rather than scalar stmt. This is a first patch to simplify the actual fix for PR104582. 2022-02-18 Richard Biener PR tree-optimization/104582 * tree-vectorizer.h (add_stmt_cost): New overload. (record_stmt_cost): Likewise. * tree-vect-loop.cc (vect_compute_single_scalar_iteration_cost): Use add_stmt_costs. (vect_get_known_peeling_cost): Use new overloads. (vect_estimate_min_profitable_iters): Likewise. Consistently use scalar_stmt for costing versioning checks. * tree-vect-stmts.cc (record_stmt_cost): New overload. but I think this just exposes the issue. The weird thing is while this does change the cost calculations during vect the final vectorized code is exactly the same out of both version. and indeed there's no change at all in the dumps until cunrolli, which in one version unrolls more than the other, but I think that's just costing difference. So I'm disabling it to continue seeing at which pass there's actually codegen difference between these two commits.
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 --- Comment #18 from rguenther at suse dot de --- On Tue, 12 Apr 2022, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 > > --- Comment #16 from Jakub Jelinek --- > i3 is always the last, that is the ultimate insn into which the other insns > are > combined into. OK, and in case the other insns are always from the same basic-block(?) they cannot have thrown previously. Only ever i3 can retain the EH note then or, if it no longer traps, we need to remove it?
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 --- Comment #19 from Jakub Jelinek --- It is true that float_extend from a constant or constant pool memory if the constant isn't NaN should never raise any kind of exception or trap. Shouldn't we handle that in may_trap_p_1 or whatever considers the RTL potentially trapping or raising exception? At least assuming it is a conversion between modes where the outer mode can represent all the values of the inner mode.
[Bug debug/105239] New: Presence of unrelated function call makes a variable optimized out only at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105239
Bug ID: 105239
Summary: Presence of unrelated function call makes a variable
optimized out only at -Og
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dc.delia at protonmail dot com
Target Milestone: ---
In this code, the value of variable l_31 from function e is available when
debugging on line 14, which re-assigns it, and optimized out at line 27, which
uses it as a call argument for test() from an external module.
We found this at -Og. Looking at DWARF info, the update of l_31 seems not
tracked with l_31’s DIE location defined only for instructions that precede the
reassignment. At -O1/-O2/-O3 the reassignment appears to be tracked correctly
as the updated value is available when debugging.
Interestingly, by removing the call to external function nop() located right
before the call to test(..., l_31, ...), the issue disappears and the DWARF
info becomes identical to the one from -O1 for the original program.
We found this issue on x64 gcc commit 500d3f0a302 using gdb 11.2; as for gcc
releases, the issue is found in every tested version (6.4, 7.5, 8.4, 9.3, 10.3,
11.1). We were unable to pinpoint a specific optimization behind it.
$ cat a.c
short a;
int c;
short b()
{
return a;
}
void e(char f)
{
short g;
int l_57 = 0 ;
for (; c <= 0; c++)
{
int l_30 = 4073709551615, l_31 = 2, l_80 = 2;
char l_81 = l_31 = f;
g = b();
nop();
test(l_57, l_30, l_31, l_80, l_81);
}
}
int main ()
{
e(8);
}
$ cat lib.c
#include
void nop() {
printf("\n");
}
void test(int l_51, int l_57, int l_30, int l_31, int l_80, int l_81) {
printf("%d %d %d %d %d %d", l_51, l_57, l_30, l_31, l_80, l_81);
}
GDB trace:
$ gcc -Og -g a.c lib.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 17
Breakpoint 1 at 0x400566: file a.c, line 17.
(gdb) r
Starting program: /tmp/opt
Breakpoint 1, e (f=f@entry=8 '\b') at a.c:17
17 test(l_57, l_30, l_31, l_80, l_81);
(gdb) info loc
l_30 = 2080555007
l_31 =
l_80 = 2
l_81 = 8 '\b'
g =
l_57 = 0
Code at -Og:
0040054e :
40054e: 55 push %rbp
40054f: 53 push %rbx
400550: 48 83 ec 08 sub$0x8,%rsp
400554: 89 fd mov%edi,%ebp
400556: eb 33 jmp40058b
400558: 40 0f be dd movsbl %bpl,%ebx
40055c: b8 00 00 00 00 mov$0x0,%eax
400561: e8 4d 00 00 00 callq 4005b3
400566: 89 da mov%ebx,%edx
400568: 41 89 d8mov%ebx,%r8d
40056b: b9 02 00 00 00 mov$0x2,%ecx
400570: be ff bf 02 7c mov$0x7c02bfff,%esi
400575: bf 00 00 00 00 mov$0x0,%edi
40057a: b8 00 00 00 00 mov$0x0,%eax
40057f: e8 42 00 00 00 callq 4005c6
400584: 83 05 b1 0a 20 00 01addl $0x1,0x200ab1(%rip)#
60103c
40058b: 83 3d aa 0a 20 00 00cmpl $0x0,0x200aaa(%rip)#
60103c
400592: 7e c4 jle400558
400594: 48 83 c4 08 add$0x8,%rsp
400598: 5b pop%rbx
400599: 5d pop%rbp
40059a: c3 retq
DWARF at -Og:
0x011f: DW_TAG_variable
DW_AT_name ("l_31")
DW_AT_decl_line (13)
DW_AT_decl_column (0x24)
DW_AT_type (0x005b "int")
DW_AT_location (0x0034:
[0x00400558, 0x0040055c): DW_OP_lit2,
DW_OP_stack_value)
DW_AT_GNU_locviews (0x0032)
Code at -O1:
0040054e :
40054e: 83 3d e7 0a 20 00 00cmpl $0x0,0x200ae7(%rip)#
60103c
400555: 7f 42 jg 400599
400557: 53 push %rbx
400558: 40 0f be df movsbl %dil,%ebx
40055c: b8 00 00 00 00 mov$0x0,%eax
400561: e8 4c 00 00 00 callq 4005b2
400566: 41 89 d8mov%ebx,%r8d
400569: b9 02 00 00 00 mov$0x2,%ecx
40056e: 89 da mov%ebx,%edx
400570: be ff bf 02 7c mov$0x7c02bfff,%esi
400575: bf 00 00 00 00 mov$0x0,%edi
40057a: b8 00 00 00 00 mov$0x0,%eax
40057f: e8 41 00 00 00 callq 4005c5
400584: 8b 05 b2 0a 20 00 mov0x200ab2(%rip),%eax#
60103c
40058a: 83 c0 01add$0x1,%eax
40058d:
[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 --- Comment #20 from rguenther at suse dot de --- On Tue, 12 Apr 2022, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 > > --- Comment #19 from Jakub Jelinek --- > It is true that float_extend from a constant or constant pool memory if the > constant isn't NaN should never raise any kind of exception or trap. > Shouldn't we handle that in may_trap_p_1 or whatever considers the RTL > potentially trapping or raising exception? > At least assuming it is a conversion between modes where the outer mode can > represent all the values of the inner mode. I'm not sure that's a general enough fix though since we seem to drop the REG_EQUAL note and as soon as we do that there's a disconnect between what CFG generation thinks throws and what combine thinks is good enough to put a REG_EH_REGION note on. It also looks like on RTL there's no way to mark an RTX as not trapping/throwing.
[Bug c++/105233] Incorrect "alignment not an integer constant" error in alignas with template parameter dependent argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105233
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Slightly reduced:
template
struct __int_traits {
static constexpr int __digits = sizeof (T) * 8;
static constexpr T __max = ~(T) 0;
};
namespace std __attribute__ ((__visibility__ ("default")))
{
template
constexpr int
__countl_zero(_Tp __x) noexcept
{
constexpr auto _Nd = __int_traits<_Tp>::__digits;
if (__x == 0)
return _Nd;
constexpr auto _Nd_ull = __int_traits::__digits;
constexpr auto _Nd_ul = __int_traits::__digits;
constexpr auto _Nd_u = __int_traits::__digits;
if constexpr (_Nd <= _Nd_u)
{
constexpr int __diff = _Nd_u - _Nd;
return __builtin_clz(__x) - __diff;
}
else if constexpr (_Nd <= _Nd_ul)
{
constexpr int __diff = _Nd_ul - _Nd;
return __builtin_clzl(__x) - __diff;
}
else if constexpr (_Nd <= _Nd_ull)
{
constexpr int __diff = _Nd_ull - _Nd;
return __builtin_clzll(__x) - __diff;
}
else
{
static_assert(_Nd <= (2 * _Nd_ull),
"Maximum supported integer size is 128-bit");
unsigned long long __high = __x >> _Nd_ull;
if (__high != 0)
{
constexpr int __diff = (2 * _Nd_ull) - _Nd;
return __builtin_clzll(__high) - __diff;
}
constexpr auto __max_ull = __int_traits::__max;
unsigned long long __low = __x & __max_ull;
return (_Nd - _Nd_ull) + __builtin_clzll(__low);
}
}
template
constexpr _Tp
__bit_ceil(_Tp __x) noexcept
{
constexpr auto _Nd = __int_traits<_Tp>::__digits;
if (__x == 0 || __x == 1)
return 1;
auto __shift_exponent = _Nd - std::__countl_zero((_Tp)(__x - 1u));
if (!__builtin_is_constant_evaluated())
{
;
}
return (_Tp)1u << __shift_exponent;
}
}
template
struct Data {
T m_a;
T m_b;
T m_c;
};
template
struct alignas(std::__bit_ceil(sizeof(Data))) AlignedData {
Data m_data;
};
AlignedData g_test;
Seems it is the if (!__builtin_is_constant_evaluated()) { ; }
part.
[Bug target/105215] IA64: ICE on openssl-1.1.1n in create_block_for_bookkeeping, at sel-sched.cc:4549 -O3 -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105215 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #2 from Martin Liška --- Ok, so it's something much older when one uses: -O3 -fvar-tracking-assignments -gstatement-frontiers -c can be seen at least with GCC 9.
[Bug c++/105233] Incorrect "alignment not an integer constant" error in alignas with template parameter dependent argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105233
--- Comment #2 from Jakub Jelinek ---
// If the shift exponent equals _Nd then the correct result is not
// representable as a value of _Tp, and so the result is undefined.
// Want that undefined behaviour to be detected in constant expressions,
// by UBSan, and by debug assertions.
if (!std::__is_constant_evaluated())
{
__glibcxx_assert( __shift_exponent != __int_traits<_Tp>::__digits );
}
is what is in the header.
[Bug target/105219] [12 Regression] SVE: Wrong code with -O3 -msve-vector-bits=128 -mtune=thunderx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105219 --- Comment #8 from Tamar Christina --- looks like the code out of the vectorizer is fine, and between the two versions it doesn't change. The big change is in the unroller, decides to drops one of the BBs for some reason. It turns the loop mask phi node from # loop_mask_374 = PHI into # loop_mask_374 = PHI and deletes the BB 68. And indeed -fdisable-tree-cunroll fixes the problem. It looks like BB68 in the broken version is being marked as unreachable by DFA and removed. Curiously with no codegen difference in output of vect, or in dce6 and pcom, the DFA in cunroll find different number of BBs good: Incremental SSA update started at block: 3 Number of blocks in CFG: 88 Number of blocks to update: 37 ( 42%) Affected blocks: 4 18 28 34 45 47 50 51 53 54 56 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 bad: Incremental SSA update started at block: 3 Number of blocks in CFG: 86 Number of blocks to update: 35 ( 41%) Affected blocks: 4 18 28 34 45 47 50 51 53 54 56 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 why did it lose 2 BBs? Is there some info missing from the dump files here?
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 Martin Liška changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105063 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-04-12 --- Comment #1 from Martin Liška --- Thanks for the bug report. I think you described very similar problem to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063. Can you check the suggested patch in the PR, please?
[Bug tree-optimization/101755] [12 regression] gcc.target/arm/reg_equal_test.c fails on arm since r12-2637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101755 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-04-12 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot gnu.org --- Comment #4 from Richard Earnshaw --- Mine
[Bug c++/105233] Incorrect "alignment not an integer constant" error in alignas with template parameter dependent argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105233
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2022-04-12
Status|UNCONFIRMED |NEW
--- Comment #3 from Jakub Jelinek ---
Slightly more reduced:
template
constexpr _Tp
foo (_Tp __x) noexcept
{
if (!__builtin_is_constant_evaluated ())
{
;
}
return 4 * __alignof (int);
}
template
struct A { T a, b, c; };
template
struct alignas (foo (sizeof (A))) B { A d; };
B e;
And we reject this since __builtin_is_constant_evaluated has been in
r9-2311-ge408261123697a82b5965c700fa2465999f0fd62 .
[Bug tree-optimization/101755] [12 regression] gcc.target/arm/reg_equal_test.c fails on arm since r12-2637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101755 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:62082d278d1fc9773539244194061ab32556db4d commit r12-8108-g62082d278d1fc9773539244194061ab32556db4d Author: Richard Earnshaw Date: Tue Apr 12 13:35:27 2022 +0100 arm: fix testsuite failure of reg_equal_test.c [PR101755] The test failure in PR101755 is due to the gimple optimizers getting smarter. But really we are just testing that RTL expansion is doing the right thing and annotating a constant accordingly. So rework the test to use GIMPLE input and simplify the code entirely. Also, this test only ever worked on architecture versions with the MOVW/MOVT instructions, so check for this before running. gcc/testsuite/ChangeLog: PR target/101755 * gcc.target/arm/reg_equal_test.c: Convert to gimple test. Restrict to architectures with MOVW/MOVT.
[Bug tree-optimization/101755] [12 regression] gcc.target/arm/reg_equal_test.c fails on arm since r12-2637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101755 Richard Earnshaw changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Earnshaw --- Fixed.
[Bug target/105090] BFI instructions are not generated on arm-none-eabi-g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105090 Richard Earnshaw changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Richard Earnshaw --- I have patches for this, but they'll have to wait for GCC-13 development to start.
[Bug c++/105233] Incorrect "alignment not an integer constant" error in alignas with template parameter dependent argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105233
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Even
template
constexpr T
foo (T x) noexcept
{
bool a = __builtin_is_constant_evaluated ();
return 4 * __alignof (int);
}
template
struct A { T a, b, c; };
template
struct alignas (foo (sizeof (A))) B { A d; };
B e;
I see that the foo (sizeof (A) expression is constexpr evaluated once
without manifestly_const_eval and with allow_non_constant set, so because of
the __builtin_is_constant_evaluated () fails in that case, as it isn't a
manifestly constant evaluation but manifestly constant evaluation could appear
later.
It isn't evaluated with it later though.
alignas argument is a constant expression (or type id), so at some point it
should be evaluated with manifestly_const_eval set.
Under the hood, we transform alignas into the gnu::aligned attribute, so the
question is, shall we treat as manifestly constant expression just alignas
argument, or gnu::aligned attribute's argument as well, or some other
attribute's arguments too? And where exactly we'd evaluate those arguments?
Seems the C++ FE has cp_check_const_attributes for this, but there it just
calls:
if (EXPR_P (expr))
TREE_VALUE (arg) = fold_non_dependent_expr (expr);
which is non-manifestly constant evaluated and doesn't guarantee it will be a
constant expression (we then just error if it is not later on).
[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105238 --- Comment #2 from Esger Abbink --- There certainly is overlap yes, in particular: "(a) build directory relative paths were stored as the .gcda paths (/a/b/c/master/path/to/file.gcda becomes path/to/file.gcda)" from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063#c8 is exactly what we want (without mangling). Where the build directory would then be /home/esger/src/application in the situation described above. I am happy to test the patch, but not quite sure how to proceed. -fprofile-prefix-map is not a valid option for gcc 9 or 10 as far as I can tell. To which gcc version/branch should I apply the patch? (the other issue mentions a 10.3.x branch, but a clone of the git gcc source does not seem to have such a branch?)
[Bug c++/105233] Incorrect "alignment not an integer constant" error in alignas with template parameter dependent argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105233 --- Comment #5 from Jakub Jelinek --- Created attachment 52791 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52791&action=edit gcc12-pr105233.patch Untested patch that makes alignas and aligned attribute argument manifestly constant evaluated expression.
[Bug debug/105239] Presence of unrelated function call makes a variable optimized out only at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105239 --- Comment #1 from Richard Biener --- The difference materializes somewhere on the RTL side.
[Bug c++/105233] Incorrect "alignment not an integer constant" error in alignas with template parameter dependent argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105233 --- Comment #6 from Patrick Palka --- (In reply to Jakub Jelinek from comment #5) > Created attachment 52791 [details] > gcc12-pr105233.patch > > Untested patch that makes alignas and aligned attribute argument manifestly > constant evaluated expression. Makes sense to me FWIW
[Bug c++/104669] [11/12 Regression] ICE in is_function_default_version, at attribs.cc:1219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104669 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/105213] Extend __builtin_{un,}pack_{longdouble,ibm128} valid for soft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105213 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #2 from Segher Boessenkool --- Fixed.
[Bug libbacktrace/105240] New: backtrace_pcinfo leaks memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105240 Bug ID: 105240 Summary: backtrace_pcinfo leaks memory Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libbacktrace Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org CC: ian at gcc dot gnu.org Target Milestone: --- I'm seeing lots of leaked memory for simple uses of libbacktrace: $ valgrind --leak-check=full ./stacktrace ==297621== Memcheck, a memory error detector ==297621== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==297621== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==297621== Command: ./stacktrace ==297621== ==297621== ==297621== HEAP SUMMARY: ==297621== in use at exit: 699,881 bytes in 1,134 blocks ==297621== total heap usage: 2,469 allocs, 1,335 frees, 1,473,361 bytes allocated ==297621== ==297621== 2,286 bytes in 53 blocks are definitely lost in loss record 12 of 20 ==297621==at 0x484086F: malloc (vg_replace_malloc.c:381) ==297621==by 0x4113F5: __glibcxx_backtrace_alloc (alloc.c:57) ==297621==by 0x413672: read_lnct (dwarf.c:2543) ==297621==by 0x413672: read_line_header_format_entries (dwarf.c:2618) ==297621==by 0x415286: read_line_header (dwarf.c:2712) ==297621==by 0x415286: read_line_info (dwarf.c:2965) ==297621==by 0x415286: dwarf_lookup_pc (dwarf.c:3747) ==297621==by 0x4162B0: dwarf_fileline (dwarf.c:3935) ==297621==by 0x405B95: std::stacktrace_entry::_M_get_info(std::__cxx11::basic_string, std::allocator >*, std::__cxx11::basic_string, std::allocator >*, int*) const (stacktrace:186) ==297621==by 0x405885: std::stacktrace_entry::source_line() const (stacktrace:129) ==297621==by 0x404B08: test_assign() (stacktrace.cc:132) ==297621==by 0x40554E: main (stacktrace.cc:212) ==297621== ==297621== 46,055 bytes in 1 blocks are possibly lost in loss record 17 of 20 ==297621==at 0x484086F: malloc (vg_replace_malloc.c:381) ==297621==by 0x4113F5: __glibcxx_backtrace_alloc (alloc.c:57) ==297621==by 0x4112EA: __glibcxx_backtrace_get_view (read.c:68) ==297621==by 0x410CC3: elf_add.constprop.0 (elf.c:4381) ==297621==by 0x4111E3: __glibcxx_backtrace_initialize (elf.c:4877) ==297621==by 0x40BC47: fileline_initialize (fileline.c:261) ==297621==by 0x40BCE5: __glibcxx_backtrace_pcinfo (fileline.c:295) ==297621==by 0x405B95: std::stacktrace_entry::_M_get_info(std::__cxx11::basic_string, std::allocator >*, std::__cxx11::basic_string, std::allocator >*, int*) const (stacktrace:186) ==297621==by 0x405885: std::stacktrace_entry::source_line() const (stacktrace:129) ==297621==by 0x404B08: test_assign() (stacktrace.cc:132) ==297621==by 0x40554E: main (stacktrace.cc:212) ==297621== ==297621== LEAK SUMMARY: ==297621==definitely lost: 2,286 bytes in 53 blocks ==297621==indirectly lost: 0 bytes in 0 blocks ==297621== possibly lost: 46,055 bytes in 1 blocks ==297621==still reachable: 651,540 bytes in 1,080 blocks ==297621== suppressed: 0 bytes in 0 blocks ==297621== Reachable blocks (those to which a pointer was found) are not shown. ==297621== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==297621== ==297621== For lists of detected and suppressed errors, rerun with: -s ==297621== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) This only happens when libbacktrace uses malloc instead of mmap.
[Bug libbacktrace/105240] backtrace_pcinfo leaks memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105240
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-04-12
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
This simple C++ program:
#include
int cb_pcinfo(void*, uintptr_t, const char*, int, const char* function)
{ return function != nullptr; }
int cb(void* p, uintptr_t pc) { *static_cast(p) = pc; return 1; }
int main()
{
auto state = backtrace_create_state(nullptr, 1, nullptr, nullptr);
uintptr_t pc;
backtrace_simple(state, 0, cb, nullptr, &pc);
backtrace_pcinfo(state, pc, cb_pcinfo, nullptr, nullptr);
}
Built with:
g++ bt.cc build/libbacktrace/.libs/libbacktrace.a -I
~/src/gcc/gcc/libbacktrace/ -g
When run under valgrind shows:
valgrind --leak-check=full ./a.out
==410984== Memcheck, a memory error detector
==410984== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==410984== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==410984== Command: ./a.out
==410984==
==410984==
==410984== HEAP SUMMARY:
==410984== in use at exit: 112,638,104 bytes in 729,676 blocks
==410984== total heap usage: 729,861 allocs, 185 frees, 115,412,593 bytes
allocated
==410984==
==410984== 84 bytes in 3 blocks are definitely lost in loss record 5 of 43
==410984==at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==by 0x409283: read_lnct (dwarf.c:2543)
==410984==by 0x409283: read_line_header_format_entries (dwarf.c:2618)
==410984==by 0x40B08A: read_line_header (dwarf.c:2712)
==410984==by 0x40B08A: read_line_info (dwarf.c:2965)
==410984==by 0x40B08A: dwarf_lookup_pc (dwarf.c:3747)
==410984==by 0x40C1BE: dwarf_fileline (dwarf.c:3935)
==410984==by 0x40134E: main (bt.cc:13)
==410984==
==410984== 13,920 bytes in 1 blocks are definitely lost in loss record 25 of 43
==410984==at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==by 0x406ED6: backtrace_get_view (read.c:68)
==410984==by 0x40568A: elf_get_view (elf.c:426)
==410984==by 0x40568A: elf_add (elf.c:4329)
==410984==by 0x406BC8: phdr_callback (elf.c:4848)
==410984==by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==410984==by 0x406DDD: backtrace_initialize (elf.c:4892)
==410984==by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==by 0x40134E: main (bt.cc:13)
==410984==
==410984== 31,248 bytes in 1 blocks are possibly lost in loss record 28 of 43
==410984==at 0x48456AF: realloc (vg_replace_malloc.c:1437)
==410984==by 0x407115: backtrace_vector_release (alloc.c:159)
==410984==by 0x40CDCD: build_dwarf_data (dwarf.c:3976)
==410984==by 0x40CDCD: backtrace_dwarf_add (dwarf.c:4022)
==410984==by 0x406475: elf_add (elf.c:4749)
==410984==by 0x4060E9: elf_add (elf.c:4434)
==410984==by 0x406BC8: phdr_callback (elf.c:4848)
==410984==by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==410984==by 0x406DDD: backtrace_initialize (elf.c:4892)
==410984==by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==by 0x40134E: main (bt.cc:13)
==410984==
==410984== 69,736 bytes in 2 blocks are possibly lost in loss record 30 of 43
==410984==at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==by 0x406ED6: backtrace_get_view (read.c:68)
==410984==by 0x40568A: elf_get_view (elf.c:426)
==410984==by 0x40568A: elf_add (elf.c:4329)
==410984==by 0x406BC8: phdr_callback (elf.c:4848)
==410984==by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==410984==by 0x406DDD: backtrace_initialize (elf.c:4892)
==410984==by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==by 0x40134E: main (bt.cc:13)
==410984==
==410984== 164,768 bytes in 1 blocks are possibly lost in loss record 31 of 43
==410984==at 0x484086F: malloc (vg_replace_malloc.c:381)
==410984==by 0x406FF1: backtrace_alloc (alloc.c:57)
==410984==by 0x406ED6: backtrace_get_view (read.c:68)
==410984==by 0x405C50: elf_add (elf.c:4591)
==410984==by 0x406BC8: phdr_callback (elf.c:4848)
==410984==by 0x4D2A314: dl_iterate_phdr (dl-iteratephdr.c:75)
==410984==by 0x406DDD: backtrace_initialize (elf.c:4892)
==410984==by 0x4014B1: fileline_initialize (fileline.c:261)
==410984==by 0x401581: backtrace_pcinfo (fileline.c:295)
==410984==by 0x40134E: main (bt.cc:13)
==410984==
==410984== 174,888 bytes in 3 blocks are possibly lost in loss record 32 o
[Bug libbacktrace/105240] backtrace_pcinfo leaks memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105240 --- Comment #2 from Jonathan Wakely --- I thought it would be OK to just use the malloc configuration unconditionally within libstdc++, but it looks like I need to include the configure checks for mman.h and use mmap whenever possible. It might even be better to disable the std::stacktrace feature entirely if mmap isn't available, so we don't get these malloc leaks.
