[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #13 from Jan Hubicka --- OK, I can reproduce it even though the propagation happens in different function in dom rather than pre. The callee is again the operator++ so I start to suspect aliasing violation there. I get: ipa-modref: in build_patches.constprop/375859, call to operator++/33005 does not clobber MEM [(struct DoFCellAccessor *)_cell] 6->6 parameter of call is _cell so we disambiguate param0 with while the summary for ipa-modref stores: Limits: 32 bases, 16 refs Base 0: alias set 11 Ref 0: alias set 13 access: Parm 0 param offset:64 offset:32 size:32 max_size:32 access: Parm 0 param offset:64 offset:0 size:32 max_size:32 So this really seems that the alias set 6 is not conflicting with alias sets 11 or 13. Honza
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292
--- Comment #14 from Jan Hubicka ---
So this really seems that the alias set 6 is not conflicting with alias sets
11 or 13. active_cell is
struct active_cell_iterator active_cell;
and the code around seems SRA injected
MEM[(struct TriaRawIterator *)_cell] ={v} {CLOBBER};
MEM [(struct DoFCellAccessor *)_cell] =
cell$dof_handler_253;
MEM [(struct DoFCellAccessor *)_cell + 8B] =
cell$8$present_level_242;
MEM [(struct DoFCellAccessor *)_cell + 12B] =
cell$8$present_index_245;
MEM [(struct DoFCellAccessor *)_cell +
16B] = cell$8$tria_244;
operator++ (_cell);
MEM[(struct TriaRawIterator *)].accessor = MEM[(const struct
TriaRawIterator &)_cell].accessor;
and we CSE is acrss the call
Honza
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #15 from Jan Hubicka --- So it seems that problem is that store in operator++ is TriaObjectAcessor while read is DoFCellAccessor. I am however not sure where the type puning happens :(
[Bug ipa/97292] [11 Regression] dealII from SPECCPU 2006 no longer terminates after g:c34db4b6f8a5d80367c709309f9b00cb32630054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97292 --- Comment #17 from Jan Hubicka --- And is it again the operator++ triggering the problem? It looks like aliasing bug to me, but in a template hell and -Wstrict-aliasing=3 is happy. The reason why parameter tracking is necessary seems to be the fact that we figure out some accesses from inner calls are local to the ++ operator and do not consider them in a summary (that is correct)
[Bug bootstrap/97350] [11 Regression] Ada bootstrap fails with: self_referential_size, at stor-layout.c:172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97350 --- Comment #11 from Jan Hubicka --- In WPA we seem to see the store to vector: Propagated modref for push_without_duplicates/1089577 loads: Limits: 32 bases, 16 refs Every base stores: Limits: 32 bases, 16 refs Base 0:struct vec (alias set 544) Ref 0:unsigned int (alias set 3) Every access Base 1:union tree_node * (alias set 21) Ref 0:union tree_node * (alias set 21) Every access Propagated modref for find_placeholder_in_expr/1089578 loads: Limits: 32 bases, 16 refs Every base stores: Limits: 32 bases, 16 refs Base 0:struct vec (alias set 544) Ref 0:unsigned int (alias set 3) Every access Base 1:union tree_node * (alias set 21) Ref 0:union tree_node * (alias set 21) Every access I guess base 0, ref 0 is the length adjustment (m_num is unsigned int). What seems interesting is that find_placeholder_in_expr lives in other partition then variable_size. It is read as: Read modref for find_placeholder_in_expr/1089578 loads: Limits: 32 bases, 16 refs Every base stores: Limits: 32 bases, 16 refs Base 0: alias set 17 Ref 0: alias set 3 Every access Base 1: alias set 16 Ref 0: alias set 16 Every access so alias set 17 and 3 are vec and unsigned_int. However in fre3 we get: ipa-modref: call stmt find_placeholder_in_expr (size_8(D), _refs); ipa-modref: call to find_placeholder_in_expr/1089578 does not clobber ref: self_refs.m_vec alias sets: 11->12 This seems odd: alias set 11 and 12 seems quite different form 17 and 3. Moreover 3 is usual alias set for a builtin type (unsigned int).
[Bug bootstrap/97350] [11 Regression] Ada bootstrap fails with: self_referential_size, at stor-layout.c:172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97350
--- Comment #12 from Jan Hubicka ---
Aha, the code in question is:
# USE = nonlocal null { D.8330 D.22051 D.22054 D.22059 D.22060 } (nonlocal,
escaped, interposable)
# CLB = nonlocal null { D.8330 D.22051 D.22054 D.22059 D.22060 } (nonlocal,
escaped, interposable)
find_placeholder_in_expr (size_8(D), _refs);
# PT = nonlocal escaped null
_30 = self_refs.m_vec;
if (_30 != 0B)
goto ; [100.00%]
else
goto ; [0.00%]
[count: 7690]:
_31 = MEM[(const struct vec *)_30].m_vecpfx.m_num;
if (_31 == 0)
goto ; [0.00%]
else
goto ; [100.00%]
What we seem to optimize out is the to m_vec, here alias set 12 makes more
sense.
and indeed it seems that this is missing in the summary. Smells like a bug in
ipa_merge_modref_summary_after_inlining since the function is split and
re-merged by inliner.
[Bug bootstrap/97350] [11 Regression] Ada bootstrap fails with: self_referential_size, at stor-layout.c:172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97350 --- Comment #10 from Jan Hubicka --- OK, I was poking a bit about the problem and indeed the bootstrapped gnat with -O3 and PGO ices, while gnat built normally does not. We fail: #2 0x019b7dcb in _Z13variable_sizeP9tree_node (size=0x77448900) at ../../gcc/stor-layout.c:172 172 gcc_assert (self_refs.length () > 0); (gdb) l 167 if (TREE_CODE (t) == CALL_EXPR || self_referential_component_ref_p (t)) 168 return size; 169 170 /* Collect the list of self-references in the expression. */ 171 find_placeholder_in_expr (size, _refs); 172 gcc_assert (self_refs.length () > 0); 173 174 /* Obtain a private copy of the expression. */ 175 t = size; here the gcc_assert fires. Sadly self_refs has no debug info. Size is: unit-size align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7745f0a8 precision:128 min max > readonly arg:0 unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7746ae70 precision:8 min max context RM size RM max > readonly visited arg:0 readonly visited arg:0 readonly nothrow visited arg:0 visited arg:0 visited> arg:1 >> arg:1 > arg:1 readonly visited arg:0 arg:1 >> arg:1 readonly arg:0 readonly arg:0 readonly arg:0 readonly arg:0 readonly visited arg:0 > arg:1 readonly visited arg:0 >> arg:1 >> arg:1 > arg:2 constant 0>> .P_BOUNDS->UB0 >= .P_BOUNDS->LB0 ? (bitsizetype) (((sizetype) .P_BOUNDS->UB0 - (sizetype) .P_BOUNDS->LB0) + 1) * 8 : 0; I am not expert on Ada type sizes but it seems like well formed expression. and backtrace is: #0 _Z14internal_errorPKcz (gmsgid=0xac ) at ../../gcc/diagnostic.c:1752 #1 0x010ba114 in _Z11fancy_abortPKciS0_ (file=0x23a38a8 "in %s, at %s:%d", line=172, function=0x1e507bb "self_referential_size") at ../../gcc/diagnostic.c:1824 #2 0x019b7dcb in _Z13variable_sizeP9tree_node (size=0x77448900) at ../../gcc/stor-layout.c:172 #3 _Z13variable_sizeP9tree_node (size=0x77448900) at ../../gcc/stor-layout.c:67 #4 0x0128f4e0 in finalize_type_size (type=0x7746c3f0) at ../../gcc/stor-layout.c:1967 #5 0x0128df40 in _Z11layout_typeP9tree_node (type=0x23a38a8) at ../../gcc/stor-layout.c:2625 #6 0x0190e307 in _ZL18build_array_type_1P9tree_nodeS0_bbb.lto_priv.0 (elt_type=0x7745f3f0, index_type=0x7746c348, typeless_storage=59, shared=172, set_canonical=59) at ../../gcc/tree.c:8194 #7 0x01567bcc in _Z18gnat_to_gnu_entityiP9tree_nodeb (gnat_entity=37370024, gnu_expr=0x1e507bb, definition=59) at ../../gcc/ada/gcc-interface/decl.c:2366 #8 0x015618f5 in _Z16gnat_to_gnu_typei (gnat_entity=37370024) at ../../gcc/ada/gcc-interface/decl.c:4887 #9 0x015687a9 in _Z18gnat_to_gnu_entityiP9tree_nodeb (gnat_entity=37370024, gnu_expr=0x1e507bb, definition=59) at ../../gcc/ada/gcc-interface/decl.c:4814 #10 0x015618f5 in _Z16gnat_to_gnu_typei (gnat_entity=37370024) at ../../gcc/ada/gcc-interface/decl.c:4887 #11 0x019ea47c in gigi (gnat_root=37370024, max_gnat_node=31786939, number_name=30016059, nodes_ptr=0xac, flags_ptr=0x1ca023b, next_node_ptr=0x73, prev_node_ptr=0x0, elists_ptr=0x0, elmts_ptr=0x0, strings_ptr=0x0, string_chars_ptr=0x0, list_headers_ptr=0x0, number_file=12, file_info_ptr=0x7fffe3c0, standard_boolean=16, standard_integer=37, standard_character=107, standard_long_long_float=100, standard_exception_type=1704, gigi_operating_mode=0) at ../../gcc/ada/gcc-interface/trans.c:463 #12 0x019e406d in back_end__call_back_end (mode=(unknown: 1704)) at ../../gcc/ada/back_end.adb:155 #13 0x01928eed in _ada_gnat1drv () at ../../gcc/ada/gnat1drv.adb:1608 #14 0x01910a4b in _ZL15gnat_parse_filev.lto_priv.0 () at ../../gcc/ada/gcc-interface/misc.c:118 #15 0x019107f4 in _ZL12compile_filev.lto_priv.0 () at ../../gcc/toplev.c:460 #16 0x018f3296 in _ZN6toplev4mainEiPPc (this=0x7fffe63e, argc=21, argv=0x7fffe728) at ../../gcc/toplev.c:2321 #17 0x018f26ec in main (argc=30016059, argv=0x1ca023b) at ../../gcc/main.c:39 Breakpointing on 171 works and vector seems to be filled in. However the disasembly shows: 0x019b7db2 <+98>:callq 0x1a1c050 <_Z24find_placeholder_in_exprP9tree_nodeP3vecIS0_7va_heap6vl_ptrE> => 0x019b7db7 <+103>: mov$0x1e507bb,%edx 0x019b7dbc <+108>: mov$0xac,%esi 0x019b7dc1 <+113>: mov$0x1ca0231,%edi 0x019b7dc6 <+118>: callq 0x10ba0f0 <_Z11fancy_abortPKciS0_> so it
[Bug bootstrap/97350] [11 Regression] Ada bootstrap fails with: self_referential_size, at stor-layout.c:172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97350
--- Comment #13 from Jan Hubicka ---
bug in SCC discovery. I am testing
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 4f86b9ccea1..771a0a88f9a 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -1603,6 +1603,11 @@ make_pass_ipa_modref (gcc::context *ctxt)
static bool
ignore_edge (struct cgraph_edge *e)
{
+ /* We merge summaries of inline clones into summaries of functions they
+ are inlined to. For that reason the complete function bodies must
+ act as unit. */
+ if (!e->inline_failed)
+return false;
enum availability avail;
cgraph_node *callee = e->callee->function_or_virtual_thunk_symbol
(, e->caller);
[Bug ipa/97389] [11 Regression] Segfault in tramp3d since r11-3825-g71dbabccbfb295c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97389 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka --- Mine.
[Bug ipa/97389] [11 Regression] Segfault in tramp3d since r11-3825-g71dbabccbfb295c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97389 Jan Hubicka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jan Hubicka --- Fixed.
[Bug bootstrap/97350] [11 Regression] Ada bootstrap fails with: self_referential_size, at stor-layout.c:172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97350 --- Comment #7 from Jan Hubicka --- Interesting, i get different ICE during GIMPLE pass: slp ../../gcc/ada/libgnat/s-os_lib.adb: In function ‘system__os_lib__normalize_pathname__missed_drive_letter’: ../../gcc/ada/libgnat/s-os_lib.adb:2133:7: internal compiler error: in vect_init_pattern_stmt, at tree-vect-patterns.c:115 2133 | function Missed_Drive_Letter (Name : String) return Boolean is | ^ 0x6534d9 vect_init_pattern_stmt ../../gcc/tree-vect-patterns.c:115 0x13e2913 vect_set_pattern_stmt ../../gcc/tree-vect-patterns.c:133 0x13e2913 vect_mark_pattern_stmts ../../gcc/tree-vect-patterns.c:5287 0x13e2913 vect_pattern_recog_1 ../../gcc/tree-vect-patterns.c:5403 0x13ef3a1 vect_pattern_recog(vec_info*) ../../gcc/tree-vect-patterns.c:5543 0xcda2ce vect_slp_analyze_bb_1 ../../gcc/tree-vect-slp.c:3819 0xcda2ce vect_slp_region ../../gcc/tree-vect-slp.c:3918 0xcda2ce vect_slp_bbs ../../gcc/tree-vect-slp.c:4074 0xcdb9d8 vect_slp_function(function*) ../../gcc/tree-vect-slp.c:4125 0xcdd085 execute ../../gcc/tree-vectorizer.c:1432
[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172 --- Comment #8 from Jan Hubicka --- Generally LTO is organized into a global stream containing types, decls etc. and local streams containing funtion bodies and initializers. Global stream thus can not contain references that are local to function bodies, like SSA_NAME, beause these are not instantiated at WPA stage and thus have no meaing. The ICE is about SSA_NAME being refered by something that is in the global stream. Judging from the testcase there is probably reference to variadic type and the variadic type now has SSA_NAME in its TYPE_SIZE or so, which should not happen.
[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
--- Comment #19 from Jan Hubicka ---
get_order unwinds to:
[local count: 1073741824]:
_1 = __builtin_constant_p (size_68(D));
if (_1 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870913]:
if (size_68(D) == 0)
goto ; [21.72%]
else
goto ; [78.28%]
[local count: 420262548]:
if (size_68(D) <= 4095)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 210131274]:
_2 = size_68(D) + 18446744073709551615;
_3 = __builtin_constant_p (_2);
if (_3 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 105065637]:
_4 = (signed long) _2;
if (_4 >= 0)
goto ; [59.00%]
else
goto ; [41.00%]
... [very long code]
[local count: 105065637]:
__asm__("bsrq %1,%q0" : "=r" bitpos_75 : "rm" _2, "0" -1);
iftmp.1_73 = bitpos_75 + -11;
[local count: 210131274]:
# iftmp.1_67 = PHI <52(6), iftmp.1_73(69), 51(7), 50(8), 49(9), 48(10),
47(11), 46(12), 45(13), 44(14), 43(15), 42(16), 41(17), 40(18), 39(19), 38(20),
37(21), 36(22), 35(23), 34(24), 33(25), 32(26), 31(27), 30(28), 29(29), 28(30),
27(31), 26(32), 25(33), 24(34), 23(35), 22(36), 21(37), 20(38), 19(39), 18(40),
17(41), 16(42), 15(43), 14(44), 13(45), 12(46), 11(47), 10(48), 9(49), 8(50),
7(51), 6(52), 5(53), 4(54), 3(55), 2(56), 1(57), 0(58), -1(59), -2(60), -3(61),
-4(62), -5(63), -6(64), -7(65), -8(66), -10(68), -9(67)>
goto ; [100.00%]
[local count: 536870913]:
size_69 = size_68(D) + 18446744073709551615;
size_70 = size_69 >> 12;
__asm__("bsrq %1,%q0" : "=r" bitpos_72 : "rm" size_70, "0" -1);
_74 = bitpos_72 + 1;
[local count: 1073741824]:
# _66 = PHI <52(3), 0(4), iftmp.1_67(70), _74(71)>
return _66;
We get summary:
IPA function summary for get_order/303 inlinable
global time: 8.716289
self size: 201
global size: 201
min size: 4
self stack: 0
global stack:0
size:4.00, time:3.00
size:3.00, time:2.00, executed if:(not inlined)
size:4.00, time:2.00, executed if:(op0 not constant)
size:2.00, time:0.782800, executed if:(op0 != 0)
size:3.00, time:0.391400, executed if:(op0 > 4095) && (op0 != 0)
size:2.00, time:0.195700, executed if:(op0 > 4095) && (op0 != 0) &&
(op0 not constant)
size:3.00, time:0.173194, executed if:(op0,(# +
18446744073709551615),((signed long) #) >= 0) && (op0 > 4095) && (op0 != 0)
size:3.00, time:0.086597, executed if:(op0,(# +
18446744073709551615),(# & 4611686018427387904) == 0) && (op0,(# +
18446744073709551615),((signed long) #) >= 0) && (op0 > 4095) && (op0 != 0)
size:3.00, time:0.043299, executed if:(op0,(# +
18446744073709551615),(# & 2305843009213693952) == 0) && (op0,(# +
18446744073709551615),(# & 4611686018427387904) == 0) && (op0,(# +
18446744073709551615),((signed long) #) >= 0) && (op0 > 4095) && (op0 != 0)
size:3.00, time:0.021649, executed if:(op0,(# +
18446744073709551615),(# & 1152921504606846976) == 0) && (op0,(# +
18446744073709551615),(# & 2305843009213693952) == 0) && (op0,(# +
18446744073709551615),(# & 4611686018427387904) == 0) && (op0,(# +
18446744073709551615),((signed long) #) >= 0) && (op0 > 4095) && (op0 != 0)
size:3.00, time:0.010825, executed if:(op0,(# +
18446744073709551615),(# & 576460752303423488) == 0) && (op0,(# +
18446744073709551615),(# & 1152921504606846976) == 0) && (op0,(# +
18446744073709551615),(# & 2305843009213693952) == 0) && (op0,(# +
18446744073709551615),(# & 4611686018427387904) == 0) && (op0,(# +
18446744073709551615),((signed long) #) >= 0) && (op0 > 4095) && (op0 != 0)
size:168.00, time:0.010825, executed if:(op0,(# +
18446744073709551615),(# & 288230376151711744) == 0) && (op0,(# +
18446744073709551615),(# & 576460752303423488) == 0) && (op0,(# +
18446744073709551615),(# & 1152921504606846976) == 0) && (op0,(# +
18446744073709551615),(# & 2305843009213693952) == 0) && (op0,(# +
18446744073709551615),(# & 4611686018427387904) == 0) && (op0,(# +
18446744073709551615),((signed long) #) >= 0) && (op0 > 4095) && (op0 != 0)
calls:
__builtin_constant_p/4546 function body not available
freq:0.20 loop depth: 0 size: 0 time: 0 predicate: (op0 > 4095) && (op0
!= 0)
op0 points to local or readonly memory
__builtin_constant_p/4546
[Bug ipa/97335] [11 Regression] 525.x264_r fails with -Ofast -g -march=znver2 -flto=16 since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97335 --- Comment #10 from Jan Hubicka --- Created attachment 49338 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49338=edit disable param tracking on clones Perhaps this has chance to help.
[Bug ipa/97403] New: Ancestor jump function should be generalized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97403
Bug ID: 97403
Summary: Ancestor jump function should be generalized
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
In the following we should be able to propagate through test in ipa-cp, but we
are not.
struct foo {int bar};
__attribute__ ((noinline))
test2(int *p)
{
return *p;
}
__attribute__ ((noinline))
test (struct foo *array)
{
return test2 ([4].bar);
}
main()
{
const struct foo array[5]={{1},{2},{3},{4},{5}};
test(array);
}
[Bug ipa/97133] [11 Regression] ICE: tree code 'bind_expr' is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97133 --- Comment #3 from Jan Hubicka --- modref is a stale infoa (streaming happens after running the ipa passes and moref is last). It is Maritn Sebor's change.
[Bug ipa/97244] [11 Regression] ICE in ipa_edge_args_sum_t::duplicate at gcc/ipa-prop.c:4251 since r11-3478-gada353b87909fd6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97244 Jan Hubicka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jan Hubicka --- Fixed.
[Bug ipa/97243] [11 Regression] ICE in compute_parm_map at gcc/ipa-modref.c:1368 since r11-3478-gada353b87909fd6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97243 Jan Hubicka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jan Hubicka --- Fixed.
[Bug ipa/97235] [11 Regression] ICE in duplicate, at ipa-prop.c:4251 since r11-3478-gada353b87909fd6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97235 Jan Hubicka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #3 from Jan Hubicka --- This is the same issues at 97244 *** This bug has been marked as a duplicate of bug 97244 ***
[Bug ipa/97244] [11 Regression] ICE in ipa_edge_args_sum_t::duplicate at gcc/ipa-prop.c:4251 since r11-3478-gada353b87909fd6c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97244 Jan Hubicka changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #4 from Jan Hubicka --- *** Bug 97235 has been marked as a duplicate of this bug. ***
[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97172 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Jan Hubicka --- Martin, the infor about ipa pass being modref is stale. It happens during the final streamout.
[Bug ipa/97576] [11 Regression] ICE: verify_cgraph_node failed (error: reference to dead statement)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97576 --- Comment #2 from Jan Hubicka --- The problem here is that clone materialization invalidates statement pointers in refs. We clean these at the begining of late optimization, I guess it should be done on demand during materialization (they are not used past that point, but we do not have convenient place to clear them).
[Bug ipa/97593] [11 Regression] ICE in gt_pch_nx, at symbol-summary.h:290 since r11-4329-g67f3791f7d133214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97593 --- Comment #2 from Jan Hubicka --- Hmm, this is anoying: we can not store summary to PCH. I guess we want to collect thunks to a vector and annotate them to callgraph at finalization time :(
[Bug c/97578] ice during IPA pass: inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578 Jan Hubicka changed: What|Removed |Added CC||jakub at redhat dot com, ||mjambor at suse dot cz Component|ipa |c Summary|[11 Regression] ice during |ice during IPA pass: inline |IPA pass: inline| --- Comment #3 from Jan Hubicka --- What hits us here is the hack I needed to introduce to ipa_param_adjustments::modify_call which triggers materialization to make debug info code working. In this case redirection happens from tree-inline and materialization gets us back to tree-inline. Inliner is however not intended to be recursive (it uses bb->aux pointers and in this case it will use it twice). Martin, Jambor, it would be really great if we did not need to materialize. I do not see how attaching debug info to decls can work if caller is in one partition and callee in another. We could also just add a loop walking all such calls and trigger materialization before going to tree-inline to avoid the recursion problem, but still IMO debug info will get missing on the partitioning boundary. We could also just avoid the (ab)use of bb->aux and replace it by a vector here which would be also an option.
[Bug ipa/97576] [11 Regression] ICE: verify_cgraph_node failed (error: reference to dead statement)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97576 Jan Hubicka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Jan Hubicka --- Fixed.
[Bug jit/97867] [11 Regression] thunk_info::release breaks function calls in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97867 Jan Hubicka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Jan Hubicka --- Fixed sorry for taking so long
[Bug middle-end/98173] New: -fno-tree-pta improves tfft2 benchmark by 50% on zen and -march=natie.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98173 Bug ID: 98173 Summary: -fno-tree-pta improves tfft2 benchmark by 50% on zen and -march=natie. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- I got curious about overall effect of PTA. This compares -fno-tree-pta to -ftree-pta. There is significant regression on tfft2 (and some with tramp3d) with -march=native on zen. https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report?younger_in_days=14_in_days=0_percentage_change=0.02=03f48fb0d37c769661d30aa0f08d91bb7174cd98%2C68ee6d12fe9882223f47f81f93616577ab4e36da_user_branches=on https://lnt.opensuse.org/db_default/v4/SPEC/latest_runs_report?younger_in_days=14_in_days=0_percentage_change=0.02=03f48fb0d37c769661d30aa0f08d91bb7174cd98%2C68ee6d12fe9882223f47f81f93616577ab4e36da_user_branches=on
[Bug ipa/79506] Compile time increase after r245366 (params.def (inline-min-speedup) Change from 10 to 8.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79506 --- Comment #2 from Jan Hubicka --- badness being a very small negative number is actually normal for large functions like this one (perhaps I should print it better though). I can check from where the estimated speedup comes - perhaps we work out some loop invariants and thus anticipate invariant motion?
[Bug ipa/79506] Compile time increase after r245366 (params.def (inline-min-speedup) Change from 10 to 8.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79506 --- Comment #3 from Jan Hubicka --- Actually it is visible from the dump Scaling time by probability:0.00 means that we expect quite few values to be "almost invariant". It may come from busted BB profile of course.
[Bug target/98172] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98172 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka --- What kind of updates you propose?
[Bug middle-end/98173] -fno-tree-pta improves tfft2 benchmark by 50% on zen and -march=natie.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98173 Jan Hubicka changed: What|Removed |Added Keywords|missed-optimization | Version|11.0|unknown --- Comment #3 from Jan Hubicka --- Note that also nbench/FP EMULATION regresses on both zens but not on cabylake.
[Bug jit/97867] [11 Regression] thunk_info::release breaks function calls in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97867
--- Comment #4 from Jan Hubicka ---
Sorry, I lost track of this, because i still hit the strange linker error with
building libjit
The following ghsould fix it.
diff --git a/gcc/symtab-thunks.h b/gcc/symtab-thunks.h
index 41a684995b3..0dba2217793 100644
--- a/gcc/symtab-thunks.h
+++ b/gcc/symtab-thunks.h
@@ -167,7 +167,7 @@ inline void
thunk_info::release ()
{
if (symtab->m_thunks)
-delete (symtab->m_thunks);
+ggc_delete (symtab->m_thunks);
symtab->m_thunks = NULL;
}
#endif /* GCC_SYMTAB_THUNKS_H */
[Bug middle-end/97775] Wrong code with bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97775 --- Comment #1 from Jan Hubicka --- Forgot to say, flags to reproduce are: -Os t2.c -fno-tree-sra -fno-ipa-modref
[Bug middle-end/97775] New: Wrong code with bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97775
Bug ID: 97775
Summary: Wrong code with bitfield
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
The follwing testcase reduced from ssd/t2.c
#include
void dump (void *p, unsigned int len)
{
const char digits[17] = "0123456789abcdef";
unsigned char *a = (unsigned char *)p;
int i;
for (i = 0; i < len; i++)
{
putchar (' ');
putchar (digits[a[i] / 16]);
putchar (digits[a[i] % 16]);
}
}
void put (const char s[])
{
int i;
for (i = 0; s[i]; i++)
putchar (s[i]);
}
void new_line (void)
{
putchar ('\n');
}
struct __attribute__((scalar_storage_order("little-endian"), packed)) R1
{
unsigned S1 : 2;
unsigned I : 32;
unsigned S2 : 2;
unsigned A1 : 9;
unsigned A2 : 9;
unsigned A3 : 9;
unsigned B : 1;
};
struct R1 My_R1 = { 2, 0x12345678, 1, 0xAB, 0xCD, 0xEF, 1 };
int main (void)
{
struct R1 Local_R1;
Local_R1.B = 1;
#ifdef BAD
new_line ();
#endif
/* { dg-output "Local_R1 : e2 59 d1 48 b4 aa d9 bb.*\n" } */
Local_R1.S1 = 0;
Local_R1.I = 0;
Local_R1.S2 = 0;
Local_R1.A1 = 0;
Local_R1.A2 = 0;
Local_R1.A3 = 0;
Local_R1.B = !Local_R1.B;
put ("Local_R1 :");
dump (_R1, sizeof (struct R1));
new_line ();
/* { dg-output "Local_R1 : e5 59 d1 48 b0 a0 c1 03.*\n" } */
new_line ();
return 0;
}
Defining BAD canges output
< Local_R1 : 00 00 00 00 00 00 00 00
---
> Local_R1 : 00 00 00 00 00 00 00 80
Difference is already in fre1:
-Value numbering store Local_R1.B to _3
+Value numbering store Local_R1.B to 1
-RPO tracked 17 values available at 3 locations and 17 lattice elements
+RPO tracked 17 values available at 0 locations and 17 lattice elements
+Replaced BIT_FIELD_REF with 0 in all uses of _1 =
BIT_FIELD_REF ;
+Replaced (signed char) _1 with 0 in all uses of _2 = (signed char) _1;
+Replaced _2 >= 0 with 1 in all uses of _3 = _2 >= 0;
+Deleted redundant store Local_R1.B = _3;
+Removing dead stmt Local_R1.B = _3;
+Removing dead stmt _3 = _2 >= 0;
+Removing dead stmt _2 = (signed char) _1;
+Removing dead stmt _1 = BIT_FIELD_REF ;
main ()
{
struct R1 Local_R1;
- unsigned char _1;
- signed char _2;
- _Bool _3;
:
Local_R1.B = 1;
@@ -533,10 +540,6 @@
Local_R1.A1 = 0;
Local_R1.A2 = 0;
Local_R1.A3 = 0;
- _1 = BIT_FIELD_REF ;
- _2 = (signed char) _1;
- _3 = _2 >= 0;
- Local_R1.B = _3;
put ("Local_R1 :");
dump (_R1, 8);
new_line ();
Clearly B should be 0 and not 1.
[Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840 --- Comment #6 from Jan Hubicka --- I remember that first_field was returning non-NULL (perhaps it is derived from empty base)? My patch touched nothing on the condition: it just improved the alias analysis. So while previously we tought that the variable can be intialized by the function call _8 = __cxa_allocate_exception (48); now we are able to track and figure out that it is non-escaping and thus can not be touched by it.
[Bug rtl-optimization/97836] [11 Regression] wrong code at -O1 on x86_64-pc-linux-gnu by r11-5029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97836 --- Comment #5 from Jan Hubicka --- I forgot to attach the PR number, but I commited the quick fix (to prevent wrong code) as g:26285af40f98dfdb809b98b08386073c63b65db1 I will discuss the EAF_UNUSED flag today after teaching.
[Bug ipa/97757] [11 Regression] fortran save_6.f90 fails with a segv for -flto -O >= 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97757 --- Comment #3 from Jan Hubicka --- This is problem with propagate_in_scc sometimes freeing the summary and losing track of it. It is fixed in https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559116.html
[Bug middle-end/97855] New: [11 regression] Bogus warning locations during lto-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97855 Bug ID: 97855 Summary: [11 regression] Bogus warning locations during lto-bootstrap Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- For a while we get odd looking locations: D.5677.coeffs[0]’../../gcc/calls.c: In function ‘expand_call’: ../../gcc/dojump.c:118:28: warning: may be used uninitialized in this function [-Wmaybe-uninitialized] 118 | pending_stack_adjust = save->x_pending_stack_adjust; |^ D.5677.coeffs[0]’../../gcc/calls.c:4082:34: note: was declared here 4082 | saved_pending_stack_adjust save; | ^ D.5677.coeffs[0]’../../gcc/dojump.c:119:27: warning: may be used uninitialized in this function [-Wmaybe-uninitialized] 119 | stack_pointer_delta = save->x_stack_pointer_delta; | ^ D.5677.coeffs[0]’../../gcc/calls.c:4082:34: note: was declared here 4082 | saved_pending_stack_adjust save; | ^ This is not due to parallel write and seems that location code somehow conclude to output the additional D.5677.coeffs[0]’
[Bug objc/97854] New: [11 regression] ODR violation in stub-objc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97854
Bug ID: 97854
Summary: [11 regression] ODR violation in stub-objc.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
stub-objc provides dummy RID enum which causes ODR violation.
This produces warnings with lto-bootstrap:
../../gcc/c-family/c-common.h:63: warning: type ‘rid’ violates the C++ One
Definition Rule [-Wodr]
63 | enum rid
|
../../gcc/c-family/stub-objc.c:30: note: an enum with different value name is
defined in another translation unit
30 | enum rid { DUMMY };
|
../../gcc/c-family/c-common.h:67: note: name ‘RID_STATIC’ differs from name
‘DUMMY’ defined in another translation unit
67 | RID_STATIC = 0,
|
../../gcc/c-family/stub-objc.c:30: note: mismatching definition
30 | enum rid { DUMMY };
|
../../gcc/c-family/c-common.h:63: warning: type ‘rid’ violates the C++ One
Definition Rule [-Wodr]
63 | enum rid
|
../../gcc/c-family/stub-objc.c:30: note: an enum with different value name is
defined in another translation unit
30 | enum rid { DUMMY };
|
../../gcc/c-family/c-common.h:67: note: name ‘RID_STATIC’ differs from name
‘DUMMY’ defined in another translation unit
67 | RID_STATIC = 0,
|
../../gcc/c-family/stub-objc.c:30: note: mismatching definition
30 | enum rid { DUMMY };
|
I think this was introduced in g:9a34a5cce6b50fc3527e7c7ab356808ed435883c
[Bug bootstrap/97857] [11 Regression] profiledbootstrap broken freeing speculative call summary since r11-4987-g602c6cfc79ce4ae61e277107e0a60079c1a93a97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857
--- Comment #8 from Jan Hubicka ---
In my setup I get ICE segfault with
#0 0x011fcf44 in vec::release (this=0x0) at ../../gcc/vec.h:1811
#1 0x011fcf2f in auto_vec::~auto_vec
(this=, this=) at ../../gcc/vec.h:1542
#2 speculative_call_summary::~speculative_call_summary (this=,
this=) at ../../gcc/ipa-profile.c:178
#3 object_allocator::remove (object=0x0,
this=0x2c980f8) at ../../gcc/alloc-pool.h:522
#4 call_summary_base::release (this=0x2c980c0,
item=0x0) at ../../gcc/symbol-summary.h:625
#5 0x00d03fbf in
call_summary::~call_summary (this=,
this=) at ../../gcc/hash-map.h:270
#6 0x011e1070 in
ipa_profile_call_summaries::~ipa_profile_call_summaries (this=,
this=) at ../../gcc/ipa-profile.c:192
#7 ipa_profile_call_summaries::~ipa_profile_call_summaries (this=, this=) at ../../gcc/ipa-profile.c:192
#8 0x011e0d00 in ipa_profile () at ../../gcc/ipa-profile.c:1031
#9 (anonymous namespace)::pass_ipa_profile::execute (this=) at
../../gcc/ipa-profile.c:1070
#10 0x00d01344 in execute_one_pass (pass=0x1cc8fe0) at
../../gcc/passes.c:2564
#11 0x011ded75 in execute_ipa_pass_list (pass=0x1cc8fe0) at
../../gcc/passes.c:2993
#12 0x00cffe1f in ipa_passes () at ../../gcc/cgraphunit.c:2217
#13 symbol_table::compile (this=0x77066100) at ../../gcc/cgraphunit.c:2294
#14 0x011cb792 in symbol_table::finalize_compilation_unit
(this=0x77066100) at ../../gcc/cgraphunit.c:2542
#15 compile_file () at ../../gcc/toplev.c:485
#16 0x0119744d in do_compile () at ../../gcc/toplev.c:2321
#17 toplev::main (argv=, argc=6, this=) at
../../gcc/toplev.c:2460
#18 main (argc=, argv=0x7fffeb08) at ../../gcc/main.c:39
What is wrong is already
#4 call_summary_base::release (this=0x2c980c0,
item=0x0) at ../../gcc/symbol-summary.h:625
625 m_allocator.remove (item);
here item should be non-NULL. This is called from:
template
call_summary::~call_summary ()
{
this->unregister_hooks ();
/* Release all summaries. */
typedef typename hash_map ::iterator map_iterator;
for (map_iterator it = m_map.begin (); it != m_map.end (); ++it)
this->release ((*it).second);
}
and here
Dump of assembler code for function
call_summary::~call_summary():
0x00d03f9e <+94>:movaps %xmm0,(%rsp)
0x00d03fa2 <+98>:callq 0xd16140
, thunk_info*,
simple_hashmap_traits >, thunk_info*>
>::hash_entry, false, xcallocator>::iterator::slide()>
0x00d03fa7 <+103>: movdqa (%rsp),%xmm2
0x00d03fac <+108>: movaps %xmm2,0x10(%rsp)
0x00d03fb1 <+113>: jmp0xd03fcf
::~call_summary()+143>
0x00d03fb3 <+115>: mov0x8(%rdx),%rsi
0x00d03fb7 <+119>: mov%rbx,%rdi
0x00d03fba <+122>: callq 0x11fcf10
::release(speculative_call_summary*)>
=> 0x00d03fbf <+127>: lea0x10(%rsp),%rdi
0x00d03fc4 <+132>: addq $0x10,0x10(%rsp)
0x00d03fca <+138>: callq 0xd16140
, thunk_info*,
simple_hashmap_traits >, thunk_info*>
>::hash_entry, false, xcallocator>::iterator::slide()>
0x00d03fcf <+143>: mov0x10(%rsp),%rdx
0x00d03fd4 <+148>: test %rdx,%rdx
so clearly ICF happens on iterator::slide() and something goes wrong here.
We merge quite a lot of slies.
[Bug bootstrap/97858] [11 regression] Bogus warnings about va_list during profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858 Jan Hubicka changed: What|Removed |Added Component|middle-end |bootstrap --- Comment #1 from Jan Hubicka --- With profiledbootstrap and no-lto this turns into error ../../libcpp/mkdeps.c: In function ‘const char* munge.constprop(const char*, const char*, ...)’: ../../libcpp/mkdeps.c:176:13: error: ‘args.__va_list_tag::reg_save_area’ may be used uninitialized [-Werror=maybe-uninitialized] 176 | str = va_arg (args, const char *); | ^ ../../libcpp/mkdeps.c:176:13: error: ‘args.__va_list_tag::overflow_arg_area’ may be used uninitialized in this function [-Werror=maybe-uninitialized] ../../libcpp/mkdeps.c:176:13: error: ‘args.__va_list_tag::gp_offset’ may be used uninitialized in this function [-Werror=maybe-uninitialized] cc1plus: all warnings being treated as errors I do not see an easy workaround since starting va_list unconditionally would be more expensive then current code.
[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535 --- Comment #15 from Jan Hubicka --- Current mainline with 1) fix to COMPONENT_REFs described above 2) improvement of ODR type having for THIS pointers 3) gimple_clobber fix (already approved) 4) compare_ao_refs fix for volatile accesses 5) compare_decs change so it does not test type compatibility of automatic vars (since these types have little meaning) 1 false returned: '' in compare_decl at ../../gcc/ipa-icf-gimple.c:163 1 false returned: 'replaceable operator flags are different' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:359 4 false returned: '' in compare_bb at ../../gcc/ipa-icf-gimple.c:606 7 false returned: 'Mismatched number of parameters' in equals_wpa at ../../gcc/ipa-icf.c:651 9 false returned: '' in compare_variable_decl at ../../gcc/ipa-icf-gimple.c:447 9 false returned: '' in operand_equal_p at ../../gcc/ipa-icf-gimple.c:312 10 false returned: 'INTEGER_CST precision mismatch' in equals at ../../gcc/ipa-icf.c:1807 11 false returned: 'case low values are different' in compare_gimple_switch at ../../gcc/ipa-icf-gimple.c:808 23 false returned: '' in operand_equal_p at ../../gcc/ipa-icf-gimple.c:303 23 false returned: 'one type is not polymorphic' in compatible_polymorphic_types_p at ../../gcc/ipa-icf-gimple.c:208 23 false returned: 'THIS pointer ODR type mismatch' in equals_wpa at ../../gcc/ipa-icf.c:678 29 false returned: 'ASM strings are different' in compare_gimple_asm at ../../gcc/ipa-icf-gimple.c:909 46 false returned: 'GIMPLE call operands are different' in compare_gimple_call at ../../gcc/ipa-icf-gimple.c:681 141 false returned: 'Declaration mismatch' in equals at ../../gcc/ipa-icf.c:1803 169 false returned: '' in compare_decl at ../../gcc/ipa-icf-gimple.c:175 182 false returned: 'DECL_CXX_DESTRUCTOR mismatch' in equals_wpa at ../../gcc/ipa-icf.c:565 246 false returned: 'final flag mismatch' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:401 391 false returned: '' in compare_phi_node at ../../gcc/ipa-icf.c:1581 391 false returned: 'PHI node comparison returns false' in equals_private at ../../gcc/ipa-icf.c:922 571 false returned: 'compare_ao_refs failed (dependence clique difference)' in compare_operand at ../../gcc/ipa-icf-gimple.c:373 676 false returned: 'compare_ao_refs failed (semantic difference)' in compare_operand at ../../gcc/ipa-icf-gimple.c:361 676 false returned: 'METHOD_TYPE and FUNCTION_TYPE mismatch' in equals_wpa at ../../gcc/ipa-icf.c:674 707 false returned: 'operand_equal_p failed' in compare_operand at ../../gcc/ipa-icf-gimple.c:381 957 false returned: 'different references' in compare_symbol_references at ../../gcc/ipa-icf.c:465 961 false returned: 'size mismatch' in equals_wpa at ../../gcc/ipa-icf.c:1652 1125 false returned: 'variables types are different' in equals at ../../gcc/ipa-icf.c:1698 1171 false returned: 'DECL_CXX_CONSTRUCTOR mismatch' in equals_wpa at ../../gcc/ipa-icf.c:562 1321 false returned: 'GIMPLE assignment operands are different' in compare_gimple_assign at ../../gcc/ipa-icf-gimple.c:724 2209 false returned: 'different decl attributes' in equals_wpa at ../../gcc/ipa-icf.c:663 4643 false returned: 'GIMPLE LHS type mismatch' in compare_gimple_assign at ../../gcc/ipa-icf-gimple.c:720 8400 false returned: 'parameter type is not compatible' in compatible_parm_types_p at ../../gcc/ipa-icf.c:512 10187 false returned: 'inline attributes are different' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:350 16210 false returned: 'parameter types are not compatible' in equals_wpa at ../../gcc/ipa-icf.c:640 26071 false returned: 'references to virtual tables cannot be merged' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:373 28810 false returned: 'decl_or_type flags are different'
[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535 --- Comment #13 from Jan Hubicka --- Actually, I did not wait long enough for ICF to finish dumping. Here is the correct output. Still nice improvement for OBJ_TYPE_REF 8399 false returned: 'parameter type is not compatible' in compatible_parm_types_p at ../../gcc/ipa-icf.c:512 10187 false returned: 'inline attributes are different' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:350 16217 false returned: 'parameter types are not compatible' in equals_wpa at ../../gcc/ipa-icf.c:639 26071 false returned: 'references to virtual tables cannot be merged' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:373 28812 false returned: 'decl_or_type flags are different' in equals_wpa at ../../gcc/ipa-icf.c:572 32287 false returned: 'different tree types' in compatible_types_p at ../../gcc/ipa-icf-gimple.c:206 60520 false returned: 'call function types are not compatible' in compare_gimple_call at ../../gcc/ipa-icf-gimple.c:635 103684 false returned: 'types are not compatible' in compatible_types_p at ../../gcc/ipa-icf-gimple.c:212 119994 false returned: 'result types are different' in equals_wpa at ../../gcc/ipa-icf.c:621 134888 false returned: '' in compare_gimple_call at ../../gcc/ipa-icf-gimple.c:607 264624 false returned: 'compare_ao_refs failed (semantic difference)' in compare_operand at ../../gcc/ipa-icf-gimple.c:336 456907 false returned: 'THIS pointer ODR type mismatch' in equals_wpa at ../../gcc/ipa-icf.c:677 460246 false returned: 'types are not same for ODR' in compatible_polymorphic_types_p at ../../gcc/ipa-icf-gimple.c:197 881974 false returned: 'operand_equal_p failed' in compare_operand at ../../gcc/ipa-icf-gimple.c:356 1011296 false returned: 'GIMPLE assignment operands are different' in compare_gimple_assign at ../../gcc/ipa-icf-gimple.c:699 1239444 false returned: '' in equals_private at ../../gcc/ipa-icf.c:886
[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535 --- Comment #14 from Jan Hubicka --- I fixed some issues 1) merging of OBJ_TYPE_REF was broken 2) last version of my COMPONENT_REF patch clears incorrectly OEP_ADDRESS_OF 3) gimple clobbers mismatches for no good reason 4) volatile memory references can are never considered equal 5) alignment of memory accesses is not hashed and may cause late mismatch (common in vector code) With this I get 141 false returned: 'Declaration mismatch' in equals at ../../gcc/ipa-icf.c:1817 162 false returned: 'DECL_CXX_DESTRUCTOR mismatch' in equals_wpa at ../../gcc/ipa-icf.c:565 169 false returned: '' in compare_decl at ../../gcc/ipa-icf-gimple.c:162 246 false returned: 'final flag mismatch' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:401 380 false returned: '' in compare_phi_node at ../../gcc/ipa-icf.c:1595 380 false returned: 'PHI node comparison returns false' in equals_private at ../../gcc/ipa-icf.c:916 513 false returned: 'different decl attributes' in equals_wpa at ../../gcc/ipa-icf.c:662 571 false returned: 'compare_ao_refs failed (dependence clique difference)' in compare_operand at ../../gcc/ipa-icf-gimple.c:368 811 false returned: 'GIMPLE call operands are different' in compare_gimple_call at ../../gcc/ipa-icf-gimple.c:676 912 false returned: 'different references' in compare_symbol_references at ../../gcc/ipa-icf.c:465 961 false returned: 'size mismatch' in equals_wpa at ../../gcc/ipa-icf.c:1666 1125 false returned: 'variables types are different' in equals at ../../gcc/ipa-icf.c:1712 1129 false returned: 'DECL_CXX_CONSTRUCTOR mismatch' in equals_wpa at ../../gcc/ipa-icf.c:562 1453 false returned: 'operand_equal_p failed' in compare_operand at ../../gcc/ipa-icf-gimple.c:376 2917 false returned: 'compare_ao_refs failed (semantic difference)' in compare_operand at ../../gcc/ipa-icf-gimple.c:356 3362 false returned: 'ctor polymorphic type mismatch' in equals_wpa at ../../gcc/ipa-icf.c:585 3527 false returned: '' in compare_decl at ../../gcc/ipa-icf-gimple.c:157 3535 false returned: '' in compare_variable_decl at ../../gcc/ipa-icf-gimple.c:442 3535 false returned: '' in operand_equal_p at ../../gcc/ipa-icf-gimple.c:307 3563 false returned: 'GIMPLE assignment operands are different' in compare_gimple_assign at ../../gcc/ipa-icf-gimple.c:719 4604 false returned: 'GIMPLE LHS type mismatch' in compare_gimple_assign at ../../gcc/ipa-icf-gimple.c:715 6577 false returned: 'parameter type is not compatible' in compatible_parm_types_p at ../../gcc/ipa-icf.c:512 8441 false returned: 'inline attributes are different' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:350 11259 false returned: 'parameter types are not compatible' in equals_wpa at ../../gcc/ipa-icf.c:639 25276 false returned: 'different tree types' in compatible_types_p at ../../gcc/ipa-icf-gimple.c:206 26073 false returned: 'references to virtual tables cannot be merged' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:373 26693 false returned: 'decl_or_type flags are different' in equals_wpa at ../../gcc/ipa-icf.c:572 61657 false returned: 'call function types are not compatible' in compare_gimple_call at ../../gcc/ipa-icf-gimple.c:655 70880 false returned: '' in equals_private at ../../gcc/ipa-icf.c:881 104034 false returned: 'types are not compatible' in compatible_types_p at ../../gcc/ipa-icf-gimple.c:212 113477 false returned: 'result types are different' in equals_wpa at ../../gcc/ipa-icf.c:621 410680 false returned: 'THIS pointer ODR type of cdtor mismatch' in equals_wpa at ../../gcc/ipa-icf.c:673 414222 false returned: 'types are not same for ODR' in compatible_polymorphic_types_p at ../../gcc/ipa-icf-gimple.c:197 and more code size savings VM SIZE FILE SIZE ++ GROWING++ [ = ] 0 .strtab +439Ki +1.0% [ = ] 0 .symtab+73.4Ki +0.4% +0.0% +32 .data +32 +0.0% -- SHRINKING -- -2.9% -2.67Mi .text -2.67Mi -2.9% -6.3% -555Ki .eh_frame -555Ki -6.3% -7.8% -148Ki .eh_frame_hdr -148Ki -7.8% -0.4% -78.2Ki .rodata-78.2Ki -0.4% -0.5% -58.8Ki .rela.dyn -58.8Ki -0.5% -0.4% -15.0Ki .data.rel.ro.local -15.0Ki -0.4% -1.0% -10.4Ki .data.rel.ro -10.4Ki -1.0% -0.0% -64 .bss 0 [ = ] -0.4% -32 .gcc_except_table -32 -0.4% -+-+-+-+-+-+-+ MIXED +-+-+-+-+-+-+- +14% +40 [Unmapped] -1.40Ki -42.6% -2.3% -3.51Mi TOTAL -3.01Mi -1.4% ICF still take quite some memory: ipa lto gimple in : 5.82 ( 4%) 2.10 ( 15%) 8.05 ( 5%) 776M ( 12%) ipa lto gimple out :
[Bug middle-end/97858] [11 regression] Bogus warnings about va_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858 Jan Hubicka changed: What|Removed |Added Status|RESOLVED|REOPENED Severity|normal |enhancement Component|bootstrap |middle-end Summary|[11 regression] Bogus |[11 regression] Bogus |warnings about va_list |warnings about va_list |during profiledbootstrap| Resolution|FIXED |--- --- Comment #10 from Jan Hubicka --- I have updated the PR to track the enhancements to -Wmaybe-uninitalized.
[Bug bootstrap/97857] [11 Regression] profiledbootstrap broken freeing speculative call summary since r11-4987-g602c6cfc79ce4ae61e277107e0a60079c1a93a97
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857 Jan Hubicka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from Jan Hubicka --- Fixed.
[Bug middle-end/97858] [11 regression] Bogus warnings about va_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858 --- Comment #11 from Jan Hubicka --- Jakub, with code patterns if (foo) ininit var ... if (foo) use var the false positive really depends on how far we do jump threading and similar transforms.
[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535 --- Comment #10 from Jan Hubicka --- Here are main reason for miscompares: 1125 libxul.so.wpa.076i.icf: false returned: 'variables types are different' in equals at ../../gcc/ipa-icf.c:1697 1171 libxul.so.wpa.076i.icf: false returned: 'DECL_CXX_CONSTRUCTOR mismatch' in equals_wpa at ../../gcc/ipa-icf.c:562 2211 libxul.so.wpa.076i.icf: false returned: 'different decl attributes' in equals_wpa at ../../gcc/ipa-icf.c:662 3362 libxul.so.wpa.076i.icf: false returned: 'ctor polymorphic type mismatch' in equals_wpa at ../../gcc/ipa-icf.c:585 3627 libxul.so.wpa.076i.icf: false returned: 'GIMPLE LHS type mismatch' in compare_gimple_assign at ../../gcc/ipa-icf-gimple.c:695 5297 libxul.so.wpa.076i.icf: false returned: '' in compare_decl at ../../gcc/ipa-icf-gimple.c:157 5304 libxul.so.wpa.076i.icf: false returned: '' in compare_variable_decl at ../../gcc/ipa-icf-gimple.c:422 5304 libxul.so.wpa.076i.icf: false returned: '' in operand_equal_p at ../../gcc/ipa-icf-gimple.c:291 8588 libxul.so.wpa.076i.icf: false returned: 'parameter type is not compatible' in compatible_parm_types_p at ../../gcc/ipa-icf.c:512 10188 libxul.so.wpa.076i.icf: false returned: 'inline attributes are different' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:350 16218 libxul.so.wpa.076i.icf: false returned: 'parameter types are not compatible' in equals_wpa at ../../gcc/ipa-icf.c:639 26076 libxul.so.wpa.076i.icf: false returned: 'references to virtual tables cannot be merged' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:373 28813 libxul.so.wpa.076i.icf: false returned: 'decl_or_type flags are different' in equals_wpa at ../../gcc/ipa-icf.c:572 32478 libxul.so.wpa.076i.icf: false returned: 'different tree types' in compatible_types_p at ../../gcc/ipa-icf-gimple.c:206 60520 libxul.so.wpa.076i.icf: false returned: 'call function types are not compatible' in compare_gimple_call at ../../gcc/ipa-icf-gimple.c:635 106399 libxul.so.wpa.076i.icf: false returned: 'types are not compatible' in compatible_types_p at ../../gcc/ipa-icf-gimple.c:212 120240 libxul.so.wpa.076i.icf: false returned: 'result types are different' in equals_wpa at ../../gcc/ipa-icf.c:621 269745 libxul.so.wpa.076i.icf: false returned: 'compare_ao_refs failed (semantic difference)' in compare_operand at ../../gcc/ipa-icf-gimple.c:336 355772 libxul.so.wpa.076i.icf: false returned: '' in compare_gimple_call at ../../gcc/ipa-icf-gimple.c:607 456913 libxul.so.wpa.076i.icf: false returned: 'THIS pointer ODR type mismatch' in equals_wpa at ../../gcc/ipa-icf.c:677 460252 libxul.so.wpa.076i.icf: false returned: 'types are not same for ODR' in compatible_polymorphic_types_p at ../../gcc/ipa-icf-gimple.c:197 1391954 libxul.so.wpa.076i.icf: false returned: 'GIMPLE assignment operands are different' in compare_gimple_assign at ../../gcc/ipa-icf-gimple.c:699 1477890 libxul.so.wpa.076i.icf: false returned: 'operand_equal_p failed' in compare_operand at ../../gcc/ipa-icf-gimple.c:356 1840986 libxul.so.wpa.076i.icf: false returned: '' in equals_private at ../../gcc/ipa-icf.c:886 So compare_ao_refs is not really a top even though it can be improved. I suppose it is time to improve the hash. Common problem is OBJ_TYPE_REF(_7;(struct nsServerSocket)_1->2) (_1); OBJ_TYPE_REF(_7;(struct nsJSProtocolHandler)_1->2) (_1); this happens 350645 (24% of the operand_equal_p failures) so I guess one can start from there. here clearly we want to hash ODR name of the OTR type.
[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535 --- Comment #9 from Jan Hubicka --- Created attachment 49578 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49578=edit Memory use of GCC trunk (11) without ICF
[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535 Jan Hubicka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #7 from Jan Hubicka --- With today trunk (after icf memory handling patches) I get VM SIZE FILE SIZE ++ GROWING++ +1.3% +1.21Mi .text +1.21Mi +1.3% +5.2% +440Ki .eh_frame +440Ki +5.2% +7.1% +126Ki .eh_frame_hdr +126Ki +7.1% +0.4% +74.8Ki .rodata+74.8Ki +0.4% +0.6% +61.0Ki .rela.dyn +61.0Ki +0.6% +0.4% +15.4Ki .data.rel.ro.local +15.4Ki +0.4% +1.1% +11.1Ki .data.rel.ro +11.1Ki +1.1% [ = ] 0 .symtab+2.55Ki +0.0% +0.0% +64 .data +64 +0.0% +0.0% +24 .rela.plt +24 +0.0% +0.0% +16 .plt +16 +0.0% +0.2% +12 .gcc_except_table +12 +0.2% +0.0% +8 .got.plt+8 +0.0% -- SHRINKING -- [ = ] 0 .strtab-29.6Ki -0.1% -0.0% -32 .bss 0 [ = ] -0.0% -8 .got-8 -0.0% -+-+-+-+-+-+-+ MIXED +-+-+-+-+-+-+- +17% +44 [Unmapped] -3.74Ki -90.8% +1.3% +1.92Mi TOTAL +1.89Mi +0.9% time report of WPA with ICF: ipa lto gimple in : 6.45 ( 4%) 2.65 ( 16%) 9.04 ( 5%) 810M ( 12%) ipa lto gimple out : 1.87 ( 1%) 0.80 ( 5%) 2.72 ( 1%) 0 ( 0%) ipa lto decl in: 18.63 ( 11%) 1.26 ( 7%) 20.02 ( 10%) 2682M ( 41%) ipa lto decl out : 4.64 ( 3%) 0.20 ( 1%) 4.84 ( 3%) 0 ( 0%) ipa icf: 17.58 ( 10%) 0.59 ( 4%) 18.22 ( 9%) 24M ( 0%) TOTAL : 176.22 16.82193.31 6617M compared to: ipa lto gimple in : 0.48 ( 0%) 0.11 ( 1%) 0.77 ( 1%) 2905k ( 0%) ipa lto gimple out : 1.01 ( 1%) 0.84 ( 8%) 1.84 ( 1%) 0 ( 0%) ipa lto decl in: 18.74 ( 14%) 1.31 ( 12%) 19.90 ( 13%) 2682M ( 47%) ipa lto decl out : 4.34 ( 3%) 0.47 ( 4%) 4.79 ( 3%) 0 ( 0%) TOTAL : 138.62 10.61149.39 5715M So still pretty bad.
[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535 --- Comment #8 from Jan Hubicka --- Created attachment 49577 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49577=edit Memory use of GCC trunk (11) with ICF
[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535 --- Comment #11 from Jan Hubicka --- Created attachment 49582 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49582=edit Memory use of GCC 10 release branch with ICF
[Bug bootstrap/97857] New: profiledbootstrap broken freeing speculative call summary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97857 Bug ID: 97857 Summary: profiledbootstrap broken freeing speculative call summary Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- Configuring with ../configure --with-build-config=bootstrap-lto --enable-checking=release --disable-plugin leads to ICE building stage feedback libstdc++. This is already with optimized cc1plus so it may a miscompile of cc1plus. 0x8fcd5a crash_signal ../../gcc/toplev.c:330 0x7789c83f ??? /build/glibc-vjB4T1/glibc-2.28/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x11fcf44 vec::release() ../../gcc/vec.h:1813 0x11fcf2e auto_vec::~auto_vec() ../../gcc/vec.h:1542 0x11fcf2e speculative_call_summary::~speculative_call_summary() ../../gcc/ipa-profile.c:178 0x11fcf2e object_allocator::remove(speculative_call_summary*) ../../gcc/alloc-pool.h:522 0x11fcf2e call_summary_base::release(speculative_call_summary*) ../../gcc/symbol-summary.h:625 0xd03fbe call_summary::~call_summary() ../../gcc/symbol-summary.h:771 0x11e106f ipa_profile_call_summaries::~ipa_profile_call_summaries() ../../gcc/ipa-profile.c:192 0x11e106f ipa_profile_call_summaries::~ipa_profile_call_summaries() ../../gcc/ipa-profile.c:192 0x11e0cff ipa_profile ../../gcc/ipa-profile.c:1031 0x11e0cff execute ../../gcc/ipa-profile.c:1070
[Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840 --- Comment #9 from Jan Hubicka --- Created attachment 49571 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49571=edit Warnings building cc1plus with LTO This is current set of wranings building cc1plus with LTO. there are 66 maybe-uninitialized. I always wondered if we want to print warnings exposing GCC internals like: ../gmp/mpz/../../../gmp/mpz/swap.c:38:3: warning: ‘MEM[(struct __mpz_struct *)]._mp_size’ may be used uninitialized in this function [-Wmaybe-uninitialized] ../gmp/mpz/../../../gmp/mpz/swap.c:37:3: warning: ‘MEM[(struct __mpz_struct *)]._mp_alloc’ may be used uninitialized in this function [-Wmaybe-uninitialized] ../isl/../../isl/isl_tab.c:2940:29: warning: ‘var’ may be used uninitialized in this function [-Wmaybe-uninitialized] ../gmp/mpz/../../../gmp/mpz/swap.c:39:3: warning: ‘MEM[(struct __mpz_struct *)]._mp_d’ may be used uninitialized in this function [-Wmaybe-uninitialized] ../gmp/mpz/../../../gmp/mpz/swap.c:38:3: warning: ‘MEM[(struct __mpz_struct *)]._mp_size’ may be used uninitialized in this function [-Wmaybe-uninitialized] ../gmp/mpz/../../../gmp/mpz/swap.c:37:3: warning: ‘MEM[(struct __mpz_struct *)]._mp_alloc’ may be used uninitialized in this function [-Wmaybe-uninitialized] ../../gcc/machmode.h:546:49: warning: ‘MEM[(struct scalar_int_mode *)_mode]’ may be used uninitialized in this function [-Wmaybe-uninitialized] A lot of warnings are about remainder_len in wide-int. Tehere is loop iniitalizeing it and seems we do not work out it has non-0 number of iteraitons. ../../gcc/analyzer/store.cc:647:13: warning: ‘MEM[(long int *)_bit_size + 8B]’ may be used uninitialized [-Wmaybe-uninitialized] ../../gcc/analyzer/store.cc:647:13: warning: ‘MEM[(long int *)_bit_size + 16B]’ may be used uninitialized [-Wmaybe-uninitialized] the MEM_REF syntax is not very pretty.
[Bug middle-end/97858] New: [11 regression] Bogus warnings about va_list during profiledbootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97858
Bug ID: 97858
Summary: [11 regression] Bogus warnings about va_list during
profiledbootstrap
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
During profiledbootstrap we get the following warnings:
../libcpp/../../libcpp/mkdeps.c: In function ‘munge.constprop’:
../libcpp/../../libcpp/mkdeps.c:176:13: warning: ‘MEM[(struct
*)].reg_save_area’ may be used uninitialized [-Wmaybe-uninitialized]
176 | str = va_arg (args, const char *);
| ^
../libcpp/../../libcpp/mkdeps.c:120:11: note: ‘MEM[(struct
*)].reg_save_area’ was declared here
120 | va_list args;
| ^
../libcpp/../../libcpp/mkdeps.c:176:13: warning: ‘MEM[(struct
*)].overflow_arg_area’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
176 | str = va_arg (args, const char *);
| ^
../libcpp/../../libcpp/mkdeps.c:120:11: note: ‘MEM[(struct
*)].overflow_arg_area’ was declared here
120 | va_list args;
| ^
../libcpp/../../libcpp/mkdeps.c:176:13: warning: ‘MEM[(struct
*)].gp_offset’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
176 | str = va_arg (args, const char *);
| ^
../libcpp/../../libcpp/mkdeps.c:120:11: note: ‘MEM[(struct *)].gp_offset’
was declared here
120 | va_list args;
| ^
This seems to be due to conditional initialization of va_list:
static const char *
munge (const char *str, const char *trail = NULL, ...)
{
static unsigned alloc;
static char *buf;
unsigned dst = 0;
va_list args;
if (trail)
va_start (args, trail);
but it does not make much sense to me to warn about internals of va_arg
iplementation at first place. It is not user visible.
[Bug ipa/92535] [10/11 regression] ICF is relatively expensive and became less effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535 --- Comment #12 from Jan Hubicka --- With ODR name hashing fix and fix to streaming the access types we now get: 957 false returned: 'different references' in compare_symbol_references at ../../gcc/ipa-icf.c:465 961 false returned: 'size mismatch' in equals_wpa at ../../gcc/ipa-icf.c:1651 1171 false returned: 'DECL_CXX_CONSTRUCTOR mismatch' in equals_wpa at ../../gcc/ipa-icf.c:562 1360 false returned: '' in compare_gimple_call at ../../gcc/ipa-icf-gimple.c:607 2209 false returned: 'different decl attributes' in equals_wpa at ../../gcc/ipa-icf.c:662 3362 false returned: 'ctor polymorphic type mismatch' in equals_wpa at ../../gcc/ipa-icf.c:585 8399 false returned: 'parameter type is not compatible' in compatible_parm_types_p at ../../gcc/ipa-icf.c:512 10161 false returned: 'inline attributes are different' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:350 16217 false returned: 'parameter types are not compatible' in equals_wpa at ../../gcc/ipa-icf.c:639 26071 false returned: 'references to virtual tables cannot be merged' in compare_referenced_symbol_properties at ../../gcc/ipa-icf.c:373 28812 false returned: 'decl_or_type flags are different' in equals_wpa at ../../gcc/ipa-icf.c:572 29308 false returned: 'different tree types' in compatible_types_p at ../../gcc/ipa-icf-gimple.c:206 99308 false returned: 'types are not compatible' in compatible_types_p at ../../gcc/ipa-icf-gimple.c:212 119994 false returned: 'result types are different' in equals_wpa at ../../gcc/ipa-icf.c:621 128276 false returned: 'compare_ao_refs failed (semantic difference)' in compare_operand at ../../gcc/ipa-icf-gimple.c:336 242454 false returned: 'operand_equal_p failed' in compare_operand at ../../gcc/ipa-icf-gimple.c:356 369360 false returned: 'GIMPLE assignment operands are different' in compare_gimple_assign at ../../gcc/ipa-icf-gimple.c:699 370952 false returned: '' in equals_private at ../../gcc/ipa-icf.c:886 456907 false returned: 'THIS pointer ODR type mismatch' in equals_wpa at ../../gcc/ipa-icf.c:677 460246 false returned: 'types are not same for ODR' in compatible_polymorphic_types_p at ../../gcc/ipa-icf-gimple.c:197 so ODR types of THIS pointers come next.
[Bug lto/80379] Redundant note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80379 --- Comment #3 from Jan Hubicka --- The problem here is that the hint is output at decl merging and -fno-strict-aliasing is a function local flag. At that time we do not even know what functions will be since units are not streamed in yet. This means that we do not know if some unit has function that is -fno-strict-aliasing. So supressing the warning does not fit the implementation very easily :(
[Bug ipa/97757] [11 Regression] fortran save_6.f90 fails with a segv for -flto -O >= 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97757 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #1 from Jan Hubicka --- indeed this is obviously garbage collected that is weird because all things should be reachable via the modref summary (where THIS pointer is taken). I will try cross.
[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008 --- Comment #6 from Jan Hubicka --- I just noticed this PR and wonder if there is anything to do on inliner side. It uses DECL_DECLARED_INLINE that was invented to distinguish between implicit inlines and explicit ones. So even if it would be bit misnamed it should mean "this is an inline hint for inliner", so I guess frontend needs to distinguish between constexpr and normal places where inline hint still means "inline more"? Inliner is really not on level to be able to completely ignore used inline hints without regressing various code. I made inline weaker for -O2 in GCC10 but for -O3 we still take it very seriously and I do not see way out of that: in many cases it is very hard to predict how much optimization will happen after inlining and a lot of code is carefully crafted under assumption that some specific inline happens (and a lot of such code is in C++)
[Bug ipa/97766] ipa/modref-2.c fails on 32 bits targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97766 Jan Hubicka changed: What|Removed |Added Last reconfirmed||2020-11-09 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jan Hubicka --- That value is sizeof(double)*8. I tpicked double since we have builtin that writes it assumed it is 64 bits on all targets. Forgot that it can be 32bit. We could change it to float. Is float of same size everywhere? If not we could restrict test only to targets where size is known.
[Bug debug/63572] [8/9/10/11 Regression] ICF breaks user debugging experience
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572 Jan Hubicka changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #24 from Jan Hubicka --- *** Bug 97937 has been marked as a duplicate of this bug. ***
[Bug ipa/97937] [11 Regression] Line numbers are missing from duplicated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97937 Jan Hubicka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jan Hubicka --- There is old PR on this *** This bug has been marked as a duplicate of bug 63572 ***
[Bug rtl-optimization/97836] [11 Regression] wrong code at -O1 on x86_64-pc-linux-gnu by r11-5029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97836
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||hubicka at gcc dot gnu.org
--- Comment #3 from Jan Hubicka ---
Confirmed.
The wrong code happens already in fre1 where we do:
main ()
{
int f;
int * _1;
:
_1 = d ();
__builtin_abort ();
}
Modref summary for d is:
loads:
Limits: 32 bases, 16 refs
Base 0: alias set 1
Ref 0: alias set 1
Every access
stores:
Limits: 32 bases, 16 refs
Base 0: alias set 1
Ref 0: alias set 1
Every access
parm 0 flags: direct noclobber noescape unused
for body:
d (int * e)
{
int D.1973;
int a.0_1;
:
a.0_1 = a;
if (a.0_1 != 0)
goto ; [INV]
else
goto ; [INV]
:
a = 0;
:
return e_10(D);
}
direct noclobber noescape looks correct to me: value is only returned and
noescape values are allowed to escape to return value (per IRC discussion we
had with Richi).
I think problem is with unused that makes tree-ssa-structalias to completely
skip the parameter rather than adding it to return value alias set.
I guess we want to specify what unused really means. Indeed current comment is
"Nonzero if the argument is not used by the function." and in this case we wold
need to have separate EAF_NOREAD so current EAF_UNUSED would be EAF_NOCLOBBER |
EAF_NOREAD or track that internally in ipa-modref.
A quick fix is to make return statement clear EAF_UNUSED flag.
[Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
Jan Hubicka changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2020-11-15
Status|UNCONFIRMED |NEW
CC||hubicka at gcc dot gnu.org
--- Comment #1 from Jan Hubicka ---
Confirmed. Reproduces on aarch64 cross for me, not on x86-64 native.
Warning is on:
#1 0x01343ad5 in maybe_warn_pass_by_reference (stmt=0x732ec558,
wlims=...) at ../../gcc/tree-ssa-uninit.c:530
530 tree argbase = maybe_warn_operand (ref, stmt, NULL_TREE, arg,
wlims);
(gdb) down
#0 maybe_warn_operand (ref=..., stmt=0x732ec558, lhs=0x0,
rhs=0x755b93f0, wlims=...) at ../../gcc/tree-ssa-uninit.c:434
434 warned = warning_at (location, OPT_Wmaybe_uninitialized,
(gdb) p debug_generic_stmt (rhs)
D.89878
std::filesystem::__cxx11::recursive_directory_iterator::pop (struct
recursive_directory_iterator * const this)
{
struct error_code ec;
struct allocator D.89878;
std::__cxx11::basic_string::basic_string<> (, iftmp.99_1,
);
D.89878 ={v} {CLOBBER};
and is otherwise unused.
Function looks identical with -fno-ipa-modref.
std::__cxx11::basic_string::basic_string<> is defined locally and the
last parameter (__a) is unused.
modref determines flags
parm 2 flags: direct noclobber noescape unused
That seems all OK to me, so it seems that somehow uninit pass gets more active
because of different alias info.
[Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840
--- Comment #2 from Jan Hubicka ---
Ok, so the warning is triggering when uninitialized memory is passed to
function argument declared as const. This happens here but is false positive
since the parameter is not used at all. This may have become worse with EAF
analysis since we now optimize the dead code initializing unused parameters in
case kill analysis triggers.
Following patch fixes it but I do not understand why this does not trigger on
x86-64 for me.
diff --git a/gcc/tree-ssa-uninit.c b/gcc/tree-ssa-uninit.c
index f23514395e0..1e074793b02 100644
--- a/gcc/tree-ssa-uninit.c
+++ b/gcc/tree-ssa-uninit.c
@@ -443,7 +443,7 @@ maybe_warn_operand (ao_ref , gimple *stmt, tree lhs,
tree rhs,
access implying read access to those objects. */
static void
-maybe_warn_pass_by_reference (gimple *stmt, wlimits )
+maybe_warn_pass_by_reference (gcall *stmt, wlimits )
{
if (!wlims.wmaybe_uninit)
return;
@@ -501,6 +501,10 @@ maybe_warn_pass_by_reference (gimple *stmt, wlimits
)
&& !TYPE_READONLY (TREE_TYPE (argtype)))
continue;
+ /* Ignore args we are not going to read from. */
+ if (gimple_call_arg_flags (stmt, argno - 1) & EAF_UNUSED)
+ continue;
+
if (save_always_executed && access->mode == access_read_only)
/* Attribute read_only arguments imply read access. */
wlims.always_executed = true;
@@ -639,8 +643,8 @@ warn_uninitialized_vars (bool wmaybe_uninit)
if (gimple_vdef (stmt))
wlims.vdef_cnt++;
- if (is_gimple_call (stmt))
- maybe_warn_pass_by_reference (stmt, wlims);
+ if (gcall *call = dyn_cast (stmt))
+ maybe_warn_pass_by_reference (call, wlims);
else if (gimple_assign_load_p (stmt)
&& gimple_has_location (stmt))
{
[Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840 --- Comment #4 from Jan Hubicka --- And to explain why warning does not trigger without modref, it is because we are not able to disambiguate the variable with another function call (since we think it escapes) (gdb) p debug_gimple_stmt (def_stmt) # .MEM_7 = VDEF <.MEM_5> _8 = __cxa_allocate_exception (48); Martin, I think this is much more your area than mine. I will post the patch on silencing warning on unused args, but I think we shoulid resovle the empty field issue.
[Bug middle-end/97840] [11 regression] Bogus -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97840 Jan Hubicka changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #3 from Jan Hubicka --- OK, on x86_64 the corresponding warning does not trigger since TYPE_EMPTY_P is true. x86_64 compiler I get: (gdb) p debug_tree (rhstype) constant 8> unit-size constant 1> align:8 warn_if_not_align:0 symtab:0 alias-set 76 canonical-type 0x77624498 fields unit-size align:8 warn_if_not_align:0 symtab:0 alias-set 77 canonical-type 0x7684a888 fields context full-name "class __gnu_cxx::new_allocator" needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=0 use_template=1 interface-unknown pointer_to_this reference_to_this chain > ignored decl_6 BLK /opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/allocator.h:116:11 size unit-size align:8 warn_if_not_align:0 offset_align 8 offset bit-offset context chain ignored decl_1 VOID /opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/allocator.h:129:9 align:1 warn_if_not_align:0 context parms value length:1 elt:0 >>> full-name "template struct std::allocator::rebind" chain >> context full-name "class std::allocator" needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=1 use_template=3 interface-only pointer_to_this reference_to_this chain > $50 = void (gdb) p rhstype->type_common.empty_flag $51 = 1 while on aarch64 I get: (gdb) p debug_tree (rhstype) constant 8> unit-size constant 1> align:8 warn_if_not_align:0 symtab:0 alias-set 76 canonical-type 0x771ff3f0 fields unit-size align:8 warn_if_not_align:0 symtab:0 alias-set 77 canonical-type 0x766297e0 fields context full-name "class __gnu_cxx::new_allocator" needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=0 use_template=1 interface-unknown pointer_to_this reference_to_this chain > ignored decl_6 BLK /opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/allocator.h:116:11 size unit-size align:8 warn_if_not_align:0 offset_align 8 offset bit-offset context chain ignored decl_1 VOID /opt/gcc/test/Build/aarch64-suse-linux/libstdc++-v3/include/bits/allocator.h:129:9 align:1 warn_if_not_align:0 context parms value length:1 elt:0 >>> full-name "template struct std::allocator::rebind" chain >> context full-name "class std::allocator" needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=1 use_template=3 interface-only pointer_to_this reference_to_this chain > $21 = void (gdb) p rhstype->type_common.empty_flag $22 = 0 that is set by 1972 /* Handle empty records as per the x86-64 psABI. */ 1973 TYPE_EMPTY_P (type) = targetm.calls.empty_record_p (type); So I suppose relying on TYPE_EMPTY_P to silence false positives on empty structures is not very portable.
[Bug c/97578] ice during IPA pass: inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578 --- Comment #8 from Jan Hubicka --- OK, I comitted patch as is and we could see if any memory can be conserved by being more precise. I still think the debug info should not need decls here. Honza
[Bug fortran/97652] New pdt14 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 --- Comment #1 from Jan Hubicka --- Actually there is another propagation happening in ipa-cp analysis: --- aa/pdt_14.f03.077i.cp 2020-10-31 09:00:52.809726530 +0100 +++ pdt_14.f03.077i.cp 2020-10-31 09:10:35.204755828 +0100 @@ -10,6 +10,8 @@ Starting walk at: push_8 (, ); instance pointer: Outer instance pointer: root offset: 0 (bits) vtbl reference: Function call may change dynamic type:push_8 (, ); +ipa-modref: call stmt push_8 (, ); +ipa-modref: call to push_8/6 does not clobber ref: root alias sets: 14->14 Determining dynamic type for call: push_8 (, ); Starting walk at: push_8 (, ); instance pointer: Outer instance pointer: C.4104 offset: 0 (bits) vtbl reference: @@ -19,6 +21,10 @@ instance pointer: Outer instance pointer: root offset: 0 (bits) vtbl reference: Function call may change dynamic type:push_8 (, ); Function call may change dynamic type:push_8 (, ); +ipa-modref: call stmt push_8 (, ); +ipa-modref: call to push_8/6 does not clobber ref: root alias sets: 14->14 +ipa-modref: call stmt push_8 (, ); +ipa-modref: call to push_8/6 does not clobber ref: root alias sets: 14->14 Determining dynamic type for call: push_8 (, ); Starting walk at: push_8 (, ); instance pointer: Outer instance pointer: C.4105 offset: 0 (bits) vtbl reference: @@ -30,6 +36,12 @@ Function call may change dynamic type:push_8 (, ); Function call may change dynamic type:push_8 (, ); Function call may change dynamic type:push_8 (, ); +ipa-modref: call stmt push_8 (, ); +ipa-modref: call to push_8/6 does not clobber ref: root alias sets: 14->14 +ipa-modref: call stmt push_8 (, ); +ipa-modref: call to push_8/6 does not clobber ref: root alias sets: 14->14 +ipa-modref: call stmt push_8 (, ); +ipa-modref: call to push_8/6 does not clobber ref: root alias sets: 14->14 Determining dynamic type for call: _3 = pop_8 (); Starting walk at: _3 = pop_8 (); instance pointer: Outer instance pointer: root offset: 0 (bits) vtbl reference: @@ -129,10 +141,14 @@ no arg info callsite ch2701/7 -> pop_8/5 : param 0: UNKNOWN + Aggregate passed by reference: + offset: 0, type: struct pdtlink_8 *, CONST: 0B value: 0x0, mask: 0xfff8 VR [1, -1] callsite ch2701/7 -> push_8/6 : param 0: UNKNOWN + Aggregate passed by reference: + offset: 0, type: struct pdtlink_8 *, CONST: 0B value: 0x0, mask: 0xfff8 VR [1, -1] param 1: CONST: -> 3.0e+0 @@ -140,6 +156,8 @@ Unknown VR callsite ch2701/7 -> push_8/6 : param 0: UNKNOWN + Aggregate passed by reference: + offset: 0, type: struct pdtlink_8 *, CONST: 0B value: 0x0, mask: 0xfff8 VR [1, -1] param 1: CONST: -> 2.0e+0 The jump function is not used for cloning, only triggers inline, but the conclusion seems wrong. push_8 can make root non-0. Root is of type pdtlink_8 so perhaps Frontend produces multiple copies of these. push_8 store is: - Analyzing store: *self_34(D) - Recording base_set=8 ref_set=8 parm=0 so indeed a different alias set than 14 used by ch2701
[Bug fortran/97652] New: New pdt14 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652
Bug ID: 97652
Summary: New pdt14 failure after
g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
pdt14 is miscompiled with -fipa-modref. This is triggered by handling fnspec,
but it seems to only trigger latent problem.
The only disambiguations are:
ipa-modref: call stmt push_8 (, );
ipa-modref: call to push_8/6 does not clobber ref:
__vtab_link_module_Pdtlink_8._deallocate alias sets: 12->11
ipa-modref: call stmt push_8 (, );
ipa-modref: call to push_8/6 does not clobber ref:
__vtab_link_module_Pdtlink_8._deallocate alias sets: 12->11
ipa-modref: call stmt push_8 (, );
ipa-modref: call to push_8/6 does not clobber ref:
__vtab_link_module_Pdtlink_8._deallocate alias sets: 12->11
ipa-modref: call stmt push_8 (, );
ipa-modref: call to push_8/6 does not clobber ref:
__vtab_link_module_Pdtlink_8._deallocate alias sets: 12->11
ipa-modref: call stmt push_8 (, );
ipa-modref: call to push_8/6 does not clobber ref:
__vtab_link_module_Pdtlink_8._deallocate alias sets: 12->11
ipa-modref: call stmt push_8 (, );
ipa-modref: call to push_8/6 does not clobber ref:
__vtab_link_module_Pdtlink_8._deallocate alias sets: 12->11
these ought to be safe since __vtab_link_module_Pdtlink_8 is readonly in the
testcase. With LTO we detect that variable as such (and the testcase stil work
without modref and fails different with modref).
fre3 does quite a lot of additional changes and I am not sure what gets wrong
here:
__attribute__((externally_visible))
main (integer(kind=4) argc, character(kind=1) * * argv)
{
+ struct array01_unknown cdesc.10;
+ struct array01_unknown cdesc.9;
+ real(kind=8) res;
+ struct Pdtlink_8 * previous;
+ struct Pdtlink_8 * current;
+ real(kind=8) res;
struct pdtlink_8 * root;
static integer(kind=4) options.11[7] = {2150, 4095, 1, 1, 1, 0, 31};
- real(kind=8) _7;
- integer(kind=4) _8;
- real(kind=8) _9;
- integer(kind=4) _10;
- real(kind=8) _11;
- integer(kind=4) _12;
- real(kind=8) _13;
- integer(kind=4) _14;
+ struct Pdtlink_8 * _15;
+ struct Pdtlink_8 * _17;
+ struct Pdtlink_8 * _21;
+ struct Pdtlink_8 * _22;
+ void (*) () _23;
+ struct Pdtlink_8 * _25;
+ void (*) () _26;
[local count: 1073741824]:
_gfortran_set_args (argc_2(D), argv_3(D));
@@ -1972,52 +2120,75 @@
push_8 (, );
push_8 (, );
push_8 (, );
- _7 = pop_8 ();
- _8 = (integer(kind=4)) _7;
- if (_8 != 3)
-goto ; [0.04%]
+ _15 = MEM[(struct Pdtlink_8 * &)];
+ if (_15 != 0B)
+goto ; [70.00%]
else
-goto ; [99.96%]
+goto ; [30.00%]
- [local count: 429496]:
- _gfortran_stop_numeric (1, 0);
-
- [local count: 1073312329]:
- _9 = pop_8 ();
- _10 = (integer(kind=4)) _9;
- if (_10 != 2)
-goto ; [0.04%]
+ [local count: 75913541732]:
+ # current_16 = PHI <_15(2), _17(3)>
+ # previous_29 = PHI <_15(2), current_16(3)>
+ _17 = current_16->next;
+ if (_17 == 0B)
+goto ; [0.00%]
else
-goto ; [99.96%]
-
- [local count: 429324]:
- _gfortran_stop_numeric (2, 0);
+goto ; [100.00%]
- [local count: 1072883005]:
- _11 = pop_8 ();
- _12 = (integer(kind=4)) _11;
- if (_12 != 1)
-goto ; [0.04%]
+ [count: 0]:
+ res_19 = current_16->n;
+ _21 = previous_29->next;
+ if (_21 == 0B)
+goto ; [30.00%]
else
-goto ; [99.96%]
+goto ; [70.00%]
- [local count: 429152]:
- _gfortran_stop_numeric (3, 0);
+ [count: 0]:
+ _22 = _15->next;
+ if (_22 != 0B)
+goto ; [70.00%]
+ else
+goto ; [30.00%]
- [local count: 1072453853]:
- _13 = pop_8 ();
- _14 = (integer(kind=4)) _13;
- if (_14 != 0)
-goto ; [0.04%]
+ [count: 0]:
+ MEM [(struct dtype_type *) + 24B] = {};
+ cdesc.9.dtype.elem_len = 24;
+ cdesc.9.dtype.rank = 1;
+ cdesc.9.dtype.type = 11;
+ cdesc.9.dim[0].lbound = 1;
+ cdesc.9.dim[0].stride = 1;
+ cdesc.9.dim[0].ubound = 1;
+ cdesc.9.data = _22;
+ _23 = __vtab_link_module_Pdtlink_8._deallocate;
+ __builtin_unreachable ();
+
+ [count: 0]:
+ __builtin_unreachable ();
+
+ [count: 0]:
+ _25 = _21->next;
+ if (_25 != 0B)
+goto ; [70.00%]
else
-goto ; [99.96%]
+goto ; [30.00%]
+
+ [count: 0]:
+ MEM [(struct dtype_type *) + 24B] = {};
+ cdesc.10.dtype.elem_len = 24;
+ cdesc.10.dtype.rank = 1;
+ cdesc.10.dtype.type = 11;
+ cdesc.10.dim[0].lbound = 1;
+ cdesc.10.dim[0].stride = 1;
+ cdesc.10.dim[0].ubound = 1;
+ cdesc.10.data = _25;
+ _26 = __vtab_link_module_Pdtlink_8._deallocate;
+ __builtin_unreachable ();
- [local count: 428981]:
- _gfortran_stop_numeric (4, 0);
+ [count: 0]:
+ __builtin_unreachable ();
- [local count: 1072024872]:
- root ={v} {CLOBBER};
- return 0;
+ [local count: 128815]:
+
[Bug fortran/97652] New pdt14 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 Jan Hubicka changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Jan Hubicka --- *** Bug 97672 has been marked as a duplicate of this bug. ***
[Bug middle-end/97672] [11 Regression] gfortran.dg/pdt_14.f03 – runtime: timeout with -O2 (and higher)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97672 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jan Hubicka --- Duplicate. I added some analysis to the other PR. It is apprently a TBAA issue in the frontend. *** This bug has been marked as a duplicate of bug 97652 ***
[Bug ipa/97445] Some fonctions marked static inline in Linux kernel are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445
Jan Hubicka changed:
What|Removed |Added
Component|c |ipa
--- Comment #48 from Jan Hubicka ---
Changing component to IPA.
Concerning comment #37 about summaries not being updated after ipa-cp, I was
actually wrong there: they are updated and the behaviour is quite sane. We work
out that kmalloc has constant argument and produce specialized clone for it.
Because it is estimated quite large it is not inlined. While when ipa-cp is
disabled we work out that inlining it will simplify body a lot and bump up the
limits.
Jakub, concerning
asm volatile ("movl $-1, %eax")
that was of course a hack. I was confused about bsr instruction - for some
time I tought it stores only 8bit value until I re-read the manual.
Honza
[Bug ipa/97445] Some fonctions marked static inline in Linux kernel are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445 Jan Hubicka changed: What|Removed |Added Depends on||97519, 97503 --- Comment #49 from Jan Hubicka --- Patch posted for the inline heuristics change https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556685.html Also opened spearate PR on builtin_constant_p folding. I am not sure how to implement that correctly (what are the conditions that make this valid - perhaps for all "i op cst" after all?) Martin, how does the if chain conversion behave on the example? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97503 [Bug 97503] Suboptimal use of cntlzw and cntlzd https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97519 [Bug 97519] builtin_constant_p (x + cst) should be optimized to builtin_constant_p (x)
[Bug tree-optimization/97519] New: builtin_constant_p (x + cst) should be optimized to builtin_constant_p (x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97519 Bug ID: 97519 Summary: builtin_constant_p (x + cst) should be optimized to builtin_constant_p (x) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- As discussed in PR97445 we should optimize builtins_constant_p (var+cst) and similar cases.
[Bug ipa/97593] [11 Regression] ICE in gt_pch_nx, at symbol-summary.h:290 since r11-4329-g67f3791f7d133214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97593 Jan Hubicka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Jan Hubicka --- Fixed.
[Bug ipa/97300] [11 regression] several test cases fail after r11-3308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97300 Jan Hubicka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Jan Hubicka --- Assumed type failures are fixed now by the Fortran array descriptor TBAA fix. g:40cb3f8ac875c6cf6610a5f93da571cfdd2a1513 If there are other failures, lets open independent PR for that.
[Bug ipa/97673] [11 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1922 since r11-4267-g0e590b68fa374365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97673 --- Comment #2 from Jan Hubicka --- This should be dup of PR97578
[Bug ipa/97698] [11 Regression] ICE: Segmentation fault (in duplicate_thunk_for_node) since r11-4587-gae7a23a3fab74
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97698 Jan Hubicka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Jan Hubicka --- Fixed.
[Bug ipa/97735] New: ipa-prop should handle simple casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97735
Bug ID: 97735
Summary: ipa-prop should handle simple casts
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Compiling:
test (int *a, int size)
{
__builtin_memset (a, 0, size);
}
gets:
Jump functions:
Jump functions of caller __builtin_memset/1:
Jump functions of caller test/0:
callsite test/0 -> __builtin_memset/1 :
param 0: PASS THROUGH: 0, op nop_expr, agg_preserved
value: 0x0, mask: 0x
Unknown VR
param 1: CONST: 0
value: 0x0, mask: 0x0
Unknown VR
param 2: UNKNOWN
value: 0x0, mask: 0x
VR ~[2147483648, -2147483649]
I think we should be able to represent that SIZE is passthrough with a
conversion.
[Bug gcov-profile/98739] New: -fprofile-reproducible is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98739 Bug ID: 98739 Summary: -fprofile-reproducible is broken Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- -fprofile-reproducible=serial leads to: jan@skylake:~> gcc -O2 -fprofile-reproducible=serial gcc: error: unknown profile reproducibility method ‘=serial’ gcc: note: valid arguments to ‘-fprofile-reproducible’ are: multithreaded parallel-runs serial; did you mean ‘serial’? gcc: fatal error: no input files compilation terminated. -fprofile-reproducibleserial is accepted but I think the implementation is broken. I think it is not enough to ignore -1 in first counter. It is also necessary to update the merge function to do right thing if I recall correctly.
[Bug ipa/98594] [11 Regression] IPA modref codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594 Jan Hubicka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jan Hubicka --- Mine. Note that the initialized warning was not really related to this problem, just to the assumption that parameters declared "const" are read by the callee which was proved false by modref and triggered false positive in the warning.
[Bug rtl-optimization/97836] wrong code at -O1 on x86_64-pc-linux-gnu by r11-5029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97836 Jan Hubicka changed: What|Removed |Added Summary|[11 Regression] wrong code |wrong code at -O1 on |at -O1 on |x86_64-pc-linux-gnu by |x86_64-pc-linux-gnu by |r11-5029 |r11-5029| --- Comment #7 from Jan Hubicka --- It is no longer regression, I will look into defining EAF_UNUSED better next stage1.
[Bug ipa/98594] [11 Regression] IPA modref codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594
--- Comment #3 from Jan Hubicka ---
The initialization is removed by dse1 pass. We get:
ipa-modref: call stmt D.3199 = bitCount::bitCount_bitfield<1, int,
glm::packed_highp> (); [return slot optimization]
ipa-modref: call to glm::vec bitCount::bitCount_bitfield(const
glm::vec&) [with int L = 1; T = int; glm::qualifier Q =
glm::packed_highp]/8 does not use ref: D.3185.D.3097.x alias sets: 3->1
Deleted dead store: D.3185.D.3097.x = x_2(D);
ipa-modref: call stmt D.3199 = bitCount::bitCount_bitfield<1, int,
glm::packed_highp> (); [return slot optimization]
ipa-modref: call to glm::vec bitCount::bitCount_bitfield(const
glm::vec&) [with int L = 1; T = int; glm::qualifier Q =
glm::packed_highp]/8 does not use ref: D.3185 alias sets: 3->3
Deleted dead store: D.3185 ={v} {CLOBBER};
Now the modref summary for function is
loads:
Limits: 32 bases, 16 refs
Base 0: alias set 5
Ref 0: alias set 5
access: Parm 0 param offset:0 offset:0 size:32 max_size:32
alias set 5 correspond to const struct vec but diferent instantiation than
alias set 3 used in the store.
There is reinterpret cast:
glm::vec::type,
Q>x(*reinterpret_cast::type,
Q> const *>());
turning it to
glm::vec::type, Q> x(*());
makes the aliasing difference go away. So it seems to me that the testcase
simply includes TBAA violation?
[Bug tree-optimization/98499] [11 Regression] Possibly bad std::string initialization in constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98499
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
CC||hubicka at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #9 from Jan Hubicka ---
Thanks for all the detailed analysis and sorry for getting into this late.
> Oh, thank you! Only after many printf() attempts it sunk in that
> `036t.ealias` is using data from seemingly later `043t.modref1` pass. It is
> so confusing!
This is because it is an inter-procedural analysis. We compile in topological
order and propagate info from function to callers.
Here I think poblem is:
void Importer::Importer (struct Importer * const this)
{
struct string * _1;
:
*this_3(D) ={v} {CLOBBER};
*this_3(D).base_path = dir_name (); [return slot optimization]
return;
}
We get parm 0 flags: direct noescape nodirectescape
While dir_name does:
struct string dir_name ()
{
:
string::string (_2(D));
return _2(D);
}
and that gets to
void string::string (struct string * const this)
{
char[16] * _1;
:
*this_3(D) ={v} {CLOBBER};
_1 = _3(D)->_M_local_buf;
*this_3(D)._M_buf = _1;
return;
}
which indeed conflict with noescape.
So problem here is that return slot optimized variables are behaving kind of
like parameters. Since modref does not track EAF flags for them I think your
conservative fix makes sense.
It is also relatively easy to track the EAF flags here, I will try to get quick
stats on how often this makes difference (and whether we want to add trakcing
now or next stage1).
Honza
[Bug c/100483] Extend -fno-semantic-interposition to global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100483
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #3 from Jan Hubicka ---
As author of the flag I agree with Alexander.
-fno-semantic-interposition basically means that variables or functions can be
interposed only if the replacement is semantically equivalent. For variables it
means that they have same constructor and for function that the effect of the
function call is the same. So it allows inter-procedural optimization across
interposable functions and constant folding of reads of constant interposable
variables.
% cat a.c
int var;
int foo() { return var; }
(I implemented this for clang 11 x86)
% clang -fpic -fno-semantic-interposition -O2 -S a.c
% cat a.s
...
foo:# @foo
.Lfoo$local:
# %bb.0:# %entry
movl.Lvar$local(%rip), %eax
retq
...
this is wrong transformation since it will break when one writes var in one DSO
and reads it from another.
I think it is misinterpretation of semantic interposition flag at clang's side.
[Bug ipa/101257] [11/12 Regression] Maybe wrong code since IPA mod ref was introduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101257 Jan Hubicka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-06-30 Ever confirmed|0 |1 --- Comment #1 from Jan Hubicka --- mine.
[Bug ipa/101270] error: inlining failed in call to ‘always_inline’ ‘open.localalias’: function not inlinable with -fPIC -fno-semantic-interposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101270 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Last reconfirmed||2021-06-30 Ever confirmed|0 |1 --- Comment #1 from Jan Hubicka --- mine.
[Bug ipa/97346] IPA reference reference_vars_to_consider leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97346 Jan Hubicka changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-08 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #3 from Jan Hubicka --- I will check If I recall correctly, during analysis the vector is only collected for dumps, so that is why vec_free is conditional. Since vec_free is noop on NULL, we could just free it anyway. I think it is the delete call that causes the leak.
[Bug ipa/99785] Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 --- Comment #16 from Jan Hubicka --- OK,we seem to handle all relevant always_inlines in early passes and then we produce functions large function with many non-always_inline calls that we spend a lot of time inlining. This is becuase we have relative function growth bounds that are quite high and we manage to get a lot of inlining done. I guess clang hits cap on those earlier. I will check if I can save some compile time. Honza
[Bug ipa/99785] Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 --- Comment #15 from Jan Hubicka --- We run into the size estimate with always inlines because after inlining we update the size of caller (because that does matter when inlining normal functions). We already have special purepose always inliner to avoid some of the issues, so I guess we keep running into this during the late IPA inlining? Honza
[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #16 from Jan Hubicka --- I was trying to reproduce some kind of ICE for a while, trying to also rebuild with ggc forced on every ggc_collect call, but no luck. I wonder if you happen to know specific gcc regression that was failing and if it was patched or not...
[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #18 from Jan Hubicka --- > Looking around the only place (we don't know whether this was WPA or LTRANS) > we'd have a cgraph with edges is during clone materialization which pointed > me at cgraph_node::release_body which frees the body but fails to eventually > zap ->call_stmt references This I agree with, but during our last discussion I went through all release_body calls and found none which would match this scenario - they are all on paths where we zap cgraph edges to (it is only makes sense to exist in this case, since we are supposed to keep cgrpah edges in sync with actual body and after feeing the body this would leave cgaph in inconsistent stage). I will try to move tree to 20210306 and see if that helps. I can simply add cgraph edge removal to release_body to make code bit more robust - while most uses erases edges earlier, it is almost free to check the pointer for being NULL twice. Still it is weird that the bug does not reproduce with allways collect.
[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #19 from Jan Hubicka --- Created attachment 50485 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50485=edit small refactoring this patch moves the removal to release_body and removes the calls on those paths where removal is done just after call to it (as opposed to being done earlier or via reset cal). But still there is no code path where it should make difference. Pehraps the assert will catch something interesting. Tests are running.
[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #20 from Jan Hubicka --- I re-tried with g:0ad6a2e2f0c667f9916cfcdb81f41f6055f1d0b3 and it builds all fine even with --param ggc-min-expand=0 --param ggc-min-heapsize=0. It seems that --enable-checking=gcac is now noop. @doko: perhaps using --param ggc-min-expand=0 --param ggc-min-heapsize=0 on your setup may trigger the problem again. There is some chance that i.e. the qt headers are the cause, but I am tempted to close the bug as WORKSFORME after committing the refactoring patch.
[Bug ipa/99751] [11 Regression] wrong code at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99751 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #7 from Jan Hubicka --- mine.
[Bug rtl-optimization/97836] wrong code at -O1 on x86_64-pc-linux-gnu by r11-5029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97836 --- Comment #8 from Jan Hubicka --- indeed, I think for gcc11 we want to make return mark value as used and for next stage1 we want to design EAF flags bit more carefully...
[Bug ipa/99751] [11 Regression] wrong code at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99751 --- Comment #8 from Jan Hubicka --- So we wrongly identify nodirectescape in store_to_c this is due to early exit in analyze_call that does not account for const call possibly returning its parameter. (An early confusion in EAF tracking logic before I settled up on the fact that returns are not escapes for local PTA). I am looking into fix. It is odd that this did not show earlier.
[Bug ipa/99751] [11 Regression] wrong code at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99751
--- Comment #9 from Jan Hubicka ---
OK, so actually there is logic to handle return values (even for consts) but it
has wrong if. I am testing the attached fix.
diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 7aaf53be8f4..5f33bb5b410 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -1545,9 +1545,9 @@ merge_call_lhs_flags (gcall *call, int arg, int index,
bool deref,
tree lhs = gimple_call_lhs (call);
analyze_ssa_name_flags (lhs, lattice, depth + 1, ipa);
if (deref)
- lattice[index].merge (lattice[SSA_NAME_VERSION (lhs)]);
- else
lattice[index].merge_deref (lattice[SSA_NAME_VERSION (lhs)], false);
+ else
+ lattice[index].merge (lattice[SSA_NAME_VERSION (lhs)]);
}
/* In the case of memory store we can do nothing. */
else
@@ -1621,7 +1621,7 @@ analyze_ssa_name_flags (tree name, vec
, int depth,
else if (gcall *call = dyn_cast (use_stmt))
{
tree callee = gimple_call_fndecl (call);
- /* Return slot optiomization would require bit of propagation;
+ /* Return slot optimization would require bit of propagation;
give up for now. */
if (gimple_call_return_slot_opt_p (call)
&& gimple_call_lhs (call) != NULL_TREE
[Bug ipa/99309] [10/11 Regression] Segmentation fault with __builtin_constant_p usage at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99309 --- Comment #5 from Jan Hubicka --- As discussed, I can prepare patch to make inliner to redirect __builtin_constant_p to __builtin_true whenever inliner detect that the expression is compile time ocnstant. This will avoid us eventually hitting unreachable when late optimizations forget to make the transformation. I was worried about this idea since this will still lead to some inconsistency since uses guarded by the __builtin_constnat_p may or may not be constant propagated and it seems logical to assume that in the block guarded by builtin_constnat_p the expression will indeed evaluate to compile time constant. However we can get similar inconsistencies with alias oracle walking limits as well, so these constructions are generally fragile (but seems increasingly common in C++ codebases). It would be still nice to have fre5 to constant propagate this. IPA analysis are very simplistics. Richi, any idea on this?
