Created attachment 41299 [details] reproducer gcc top of the trunk, r247455, x86_64 Test is quite big, I failed to reduce it. UBSAN switch is also required to reproduce. > time g++ -std=c++11 -fsanitize=undefined -w -O0 -c func.i func.cpp: In function ‘void foo()’: func.cpp:1181:1: internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126 } ^ 0xb96459 compute_inline_parameters(cgraph_node*, bool) ../../gcc_svn/gcc/ipa-inline-analysis.c:3125 0xb96668 compute_inline_parameters_for_current ../../gcc_svn/gcc/ipa-inline-analysis.c:3137 0xb96668 execute ../../gcc_svn/gcc/ipa-inline-analysis.c:3167 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. real 4m53.780s user 4m49.790s sys 0m3.985s
The attached file demonstrates the problem and only needs flags -v -w -O2.
Created attachment 41300 [details] gzipped C source code
Confirmed, started same as PR80581 with r247455. However the assert is triggered on a different location: Breakpoint 1, compute_inline_parameters (node=0x7ffff4d11e60, early=true) at ../../gcc/ipa-inline-analysis.c:3125 3125 gcc_assert (!(info->time - info->self_time).to_int () (gdb) p info->time $1 = {m_sig = 1316130052, m_exp = -10} (gdb) p info->time.to_int() $2 = 1285283 (gdb) p info->self_time.to_int() $3 = 1285282
Still broken over a week later and I notice this bug report is not assigned to anyone. I notice that hubicka has done seven of the last ten changes in the ipa-inline-analysis.c. Maybe they are the best person to comment further ?
Created attachment 41349 [details] Patch candidate Yep, it's Honza Hubicka's PR. I'm suggesting a new function that will handle round off errors in sreal. Can you please Honza take a look? Can you Dmitry test it?
(In reply to Martin Liška from comment #5) > Created attachment 41349 [details] > Patch candidate > > Yep, it's Honza Hubicka's PR. I'm suggesting a new function that will handle > round off errors in sreal. > > Can you please Honza take a look? Can you Dmitry test it? I just ran into the same ICE and the proposed patch fixes the problem.
(In reply to Pat Haugen from comment #6) > > I just ran into the same ICE and the proposed patch fixes the problem. Unfortunately the patch introduces the same ICE on another benchmark that used to build just fine.
(In reply to Pat Haugen from comment #7) > (In reply to Pat Haugen from comment #6) > > > > I just ran into the same ICE and the proposed patch fixes the problem. > > Unfortunately the patch introduces the same ICE on another benchmark that > used to build just fine. Can you please provide a test-case? Or can you dump the sreal values via .to_double() ? That can be also hint for us to fix that properly.
(In reply to Martin Liška from comment #8) > > Can you please provide a test-case? Or can you dump the sreal values via > .to_double() ? That can be also hint for us to fix that properly. I'm trying to reduce the source, but it's proprietary so will see what it reduces to before I can think about posting anything. In the meantime, here's what things look like when the assert fails. (gdb) p info->self_time $7 = {m_sig = 1347786301, m_exp = -13} (gdb) p info->self_time.to_double() $8 = 164524.69494628906 (gdb) p info->time $9 = {m_sig = 1347789465, m_exp = -13} (gdb) p info->time.to_double() $10 = 164525.08117675781
(In reply to Pat Haugen from comment #9) > (In reply to Martin Liška from comment #8) > > > > Can you please provide a test-case? Or can you dump the sreal values via > > .to_double() ? That can be also hint for us to fix that properly. > > I'm trying to reduce the source, but it's proprietary so will see what it > reduces to before I can think about posting anything. In the meantime, > here's what things look like when the assert fails. > > (gdb) p info->self_time > $7 = {m_sig = 1347786301, m_exp = -13} > (gdb) p info->self_time.to_double() > $8 = 164524.69494628906 > (gdb) p info->time > $9 = {m_sig = 1347789465, m_exp = -13} > (gdb) p info->time.to_double() > $10 = 164525.08117675781 Thanks, we'll have to soften the epsilon I guess. I'll discuss that with Honza.
Created attachment 41375 [details] Patch candidate v2 Can you please test this version? It moves e from 10^6 to 10^5.
(In reply to Martin Liška from comment #11) > Created attachment 41375 [details] > Patch candidate v2 > > Can you please test this version? It moves e from 10^6 to 10^5. That patch works for both the benchmarks that were affected.
The attached patch fixes my original test case.
Disregard my previous comment. Original test case still fails with compiler switches that I've originally reported (-fsanitize=undefined).
Created attachment 41395 [details] Patch v3 This can compile also the original test, changing epsilon to 1/1000.
(In reply to Dmitry Babokin from comment #14) > Original test case still fails with compiler switches that I've originally > reported (-fsanitize=undefined). Is your failure fixed with r248325?
Yes, it's fix with current trunk.
Fixed on trunk.