[Bug ipa/103073] [12 Regression] ICE in insert_access, at ipa-modref-tree.h:578 since r12-4401-gfecd145359fc981b

[mliska at suse dot cz via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073

--- Comment #9 from Martin Liška  ---
On 11/5/21 13:32, hubicka at kam dot mff.cuni.cz wrote:
> |+ " - Paradoxical ragne. Ignoring\n");|

s/ragne/range

[Bug tree-optimization/91351] [9/10 Regression] -fstrict-enums generates incorrect code

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91351

--- Comment #9 from Martin Liška  ---
On 8/6/19 2:54 PM, glisse at gcc dot gnu.org wrote:
> Does the enum really have a precision of 5 bits? I would have expected
> (1<<5)-11 instead of 4294967285 (i.e. (1<<32)-11), without looking at it too
> closely.

Yep, if I see correctly:


(gdb) p debug_tree(*lhs)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7780b000 precision:5 min  max >
sizes-gimplified unsigned SI size 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x777f5f18 precision:32 min  max 
values > value 
chain > value 
chain > value 
chain > value 
chain  value  chain
> context 
chain >

def_stmt _6 = e_2(D) + 4294967285;
version:6>

So the integer_type of the enumeral_type hash precision:5 and:
min 

and

max 

which is what one would expect from -fstrict-enums.

Martin

[Bug lto/90500] ICE error in copy_forbiden

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500

--- Comment #18 from Martin Liška  ---
On 5/20/19 11:58 PM, joseph at codesourcery dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90500
> 
> --- Comment #17 from joseph at codesourcery dot com  dot com> ---
> The copy attribute is intended to copy attributes that are properties of 
> the function itself (e.g. "pure"), but not those that are properties of a 
> particular symbol for the function (e.g. "visibility").  If target_clones 
> does not make sense to copy, probably it should be excluded by the copy 
> attribute.
> 

Works for me, I'm going to prepare a patch that will address that.

Thank you,
Martin

[Bug middle-end/77574] Wrong if condition in predict.c

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77574

--- Comment #1 from Martin Liška  ---
On 09/13/2016 12:30 AM, bernd.edlinger at hotmail dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77574
> 
> Bug ID: 77574
>Summary: Wrong if condition in predict.c
>Product: gcc
>Version: 7.0
> Status: UNCONFIRMED
>   Severity: normal
>   Priority: P3
>  Component: middle-end
>   Assignee: unassigned at gcc dot gnu.org
>   Reporter: bernd.edlinger at hotmail dot de
>   Target Milestone: ---
> 
> Hi,
> 
> an experimental version of my -Wint-in-bool-context patch
> found this apparently wrong code in predict.c
> 
> ../../gcc-trunk/gcc/predict.c: In function 'void force_edge_cold(edge, bool)':
> ../../gcc-trunk/gcc/predict.c:3726:36: error: ?: using integer constants in
> boolean context [-Werror=int-in-bool-context]
>if (e->probability <= impossible ? PROB_VERY_UNLIKELY : 0
>~^~~~
>&& (!impossible || !e->count))
>~ 
> 
> 
> I think it is meant this way:
>if (e->probability <= (impossible ? PROB_VERY_UNLIKELY : 0)
>&& (!impossible || !e->count))
> 

Hello Bernd.

Thanks for the PR, as well the suggested patch. The patch works for me,
I'm going to test it and submit to mailing list. Please ping me if you're
accidentally doing the same?

Thanks,
Martin

[Bug libgomp/68033] New: OpenMP: ICE with teams distribute

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68033

Bug ID: 68033
   Summary: OpenMP: ICE with teams distribute
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 36551
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36551=edit
test-case

Hello.

Using official gcc 5.1:
gcc version 5.1.1 20150713 [gcc-5-branch revision 225736] (SUSE Linux) 

$ gcc -fopenmp lud_omp.c:
#0  c_tree_printer (pp=0x1df9c90, text=, spec=0x1df4bf1 "E",
precision=, wide=, set_locus=false, hash=false)
at ../../gcc/c/c-objc-common.c:182
#1  0x012e827c in pp_format (pp=0x1df9c90, text=0x7fffc300) at
../../gcc/pretty-print.c:613
#2  0x012e44f3 in diagnostic_report_diagnostic (context=0x1daaa60
, diagnostic=0x7fffc300) at
../../gcc/diagnostic.c:865
#3  0x012e5156 in error (gmsgid=0x142e118 "%qE not specified in
enclosing parallel") at ../../gcc/diagnostic.c:1137
#4  0x00894988 in omp_notice_variable (ctx=0x1e112b0,
decl=0x76a6fcf0, in_code=) at ../../gcc/gimplify.c:5841
#5  0x008945c9 in omp_notice_variable (ctx=0x1e11250,
decl=0x76a6fcf0, in_code=) at ../../gcc/gimplify.c:5951
#6  0x008952c3 in gimplify_var_or_parm_decl
(expr_p=expr_p@entry=0x76a6c160) at ../../gcc/gimplify.c:1806
#7  0x00899424 in gimplify_expr (expr_p=expr_p@entry=0x76a6c160,
pre_p=pre_p@entry=0x7fffc6a8, post_p=0x7fffc538, post_p@entry=0x0,
gimple_test_f=, fallback=fallback@entry=1) at
../../gcc/gimplify.c:8531
#8  0x0089fafd in gimplify_omp_for (expr_p=expr_p@entry=0x76a67680,
pre_p=pre_p@entry=0x7fffc8b8) at ../../gcc/gimplify.c:7270
#9  0x008990bd in gimplify_expr (expr_p=0x76a67680,
pre_p=pre_p@entry=0x7fffc8b8, post_p=0x7fffc758, post_p@entry=0x0,
gimple_test_f=gimple_test_f@entry=0x8923f0 <is_gimple_stmt(tree)>,
fallback=fallback@entry=0) at ../../gcc/gimplify.c:8562
#10 0x0089a967 in gimplify_stmt (stmt_p=stmt_p@entry=0x76a67680,
seq_p=seq_p@entry=0x7fffc8b8) at ../../gcc/gimplify.c:5519
#11 0x0089b16e in gimplify_bind_expr
(expr_p=expr_p@entry=0x7fffcb50, pre_p=pre_p@entry=0x7fffcbb0) at
../../gcc/gimplify.c:1136
#12 0x0089943a in gimplify_expr (expr_p=0x7fffcb50,
pre_p=pre_p@entry=0x7fffcbb0, post_p=0x7fffc968, post_p@entry=0x0,
gimple_test_f=gimple_test_f@entry=0x8923f0 <is_gimple_stmt(tree)>,
fallback=fallback@entry=0) at ../../gcc/gimplify.c:8297
#13 0x0089a967 in gimplify_stmt (stmt_p=stmt_p@entry=0x7fffcb50,
seq_p=seq_p@entry=0x7fffcbb0) at ../../gcc/gimplify.c:5519
#14 0x0089a224 in gimplify_and_add (seq_p=0x7fffcbb0,
t=0x76a67660) at ../../gcc/gimplify.c:423
#15 gimplify_and_return_first (seq_p=0x7fffcbb0, t=) at
../../gcc/gimplify.c:435
#16 gimplify_omp_parallel (pre_p=0x7fffcc80, expr_p=0x7fffcc98) at
../../gcc/gimplify.c:6901
#17 gimplify_expr (expr_p=0x7fffcc98, pre_p=pre_p@entry=0x7fffcc80,
post_p=0x7fffcaf8, post_p@entry=0x0,
gimple_test_f=gimple_test_f@entry=0x8923f0 <is_gimple_stmt(tree)>,
fallback=fallback@entry=0) at ../../gcc/gimplify.c:8547
#18 0x0089a967 in gimplify_stmt (stmt_p=stmt_p@entry=0x7fffcc98,
seq_p=seq_p@entry=0x7fffcc80) at ../../gcc/gimplify.c:5519
#19 0x008a04b8 in gimplify_and_add (seq_p=0x7fffcc80,
t=0x76a6c7f8) at ../../gcc/gimplify.c:423
#20 gimplify_omp_for (expr_p=expr_p@entry=0x7fffce98,
pre_p=pre_p@entry=0x7fffce88) at ../../gcc/gimplify.c:7413
#21 0x008990bd in gimplify_expr (expr_p=0x7fffce98,
pre_p=pre_p@entry=0x7fffce88, post_p=0x7fffcd38, post_p@entry=0x0,
gimple_test_f=gimple_test_f@entry=0x8923f0 <is_gimple_stmt(tree)>,
fallback=fallback@entry=0) at ../../gcc/gimplify.c:8562
#22 0x0089a967 in gimplify_stmt (stmt_p=stmt_p@entry=0x7fffce98,
seq_p=seq_p@entry=0x7fffce88) at ../../gcc/gimplify.c:5519
#23 0x0089f639 in gimplify_and_add (seq_p=0x7fffce88,
t=0x768dad38) at ../../gcc/gimplify.c:423
#24 gimplify_omp_workshare (expr_p=expr_p@entry=0x76a676b0,
pre_p=pre_p@entry=0x7fffd098) at ../../gcc/gimplify.c:7543
#25 0x00898f89 in gimplify_expr (expr_p=0x76a676b0,
pre_p=pre_p@entry=0x7fffd098, post_p=0x7fffcf38, post_p@entry=0x0,
gimple_test_f=gimple_test_f@entry=0x8923f0 <is_gimple_stmt(tree)>,
fallback=fallback@entry=0) at ../../gcc/gimplify.c:8598
#26 0x0089a967 in gimplify_stmt (stmt_p=stmt_p@entry=0x76a676b0,
seq_p=seq_p@entry=0x7fffd098) at ../../gcc/gimplify.c:5519
#27 0x0089b16e in gimplify_bind_expr
(expr_p=expr_p@entry=0x7fffd2a0, pre_p=pre_p@entry=0x7fffd298

[Bug libgomp/68033] OpenMP: ICE with teams distribute

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68033

--- Comment #1 from Martin Liška  ---
BT in trunk branch:

#0  c_tree_printer (pp=0x2518a50, text=0x7fffb650, spec=0x2513a61 "E",
precision=, wide=, set_locus=false, hash=false)
at ../../gcc/c/c-objc-common.c:174
#1  0x0177715c in pp_format (pp=0x2518a50, text=0x7fffb650) at
../../gcc/pretty-print.c:613
#2  0x01772d8a in diagnostic_report_diagnostic (context=0x24c75c0
, diagnostic=0x7fffb650) at
../../gcc/diagnostic.c:784
#3  0x017739e2 in error (gmsgid=0x18d9728 "%qE not specified in
enclosing %s") at ../../gcc/diagnostic.c:1055
#4  0x00b046c7 in omp_default_clause (ctx=0x24f04b0,
decl=0x76a71cf0, in_code=true, flags=1) at ../../gcc/gimplify.c:5836
#5  0x00b04ec4 in omp_notice_variable (ctx=0x24f04b0,
decl=0x76a71cf0, in_code=true) at ../../gcc/gimplify.c:6004
#6  0x00b05171 in omp_notice_variable (ctx=0x2512000,
decl=0x76a71cf0, in_code=true) at ../../gcc/gimplify.c:6053
#7  0x00af5db6 in gimplify_var_or_parm_decl (expr_p=0x76a68db8) at
../../gcc/gimplify.c:1793
#8  0x00b167f7 in gimplify_expr (expr_p=0x76a68db8,
pre_p=0x7fffbba0, post_p=0x7fffb9f0, gimple_test_f=0xac7dc5
, fallback=1) at ../../gcc/gimplify.c:9557
#9  0x00b100c9 in gimplify_omp_for (expr_p=0x76a69e30,
pre_p=0x7fffbf78) at ../../gcc/gimplify.c:8038
#10 0x00b168a7 in gimplify_expr (expr_p=0x76a69e30,
pre_p=0x7fffbf78, post_p=0x7fffbdd0, gimple_test_f=0xaff86b
, fallback=0) at ../../gcc/gimplify.c:9589
#11 0x00b038ea in gimplify_stmt (stmt_p=0x76a69e30,
seq_p=0x7fffbf78) at ../../gcc/gimplify.c:5551
#12 0x00af357d in gimplify_bind_expr (expr_p=0x7fffc238,
pre_p=0x7fffc2a8) at ../../gcc/gimplify.c:1123
#13 0x00b15865 in gimplify_expr (expr_p=0x7fffc238,
pre_p=0x7fffc2a8, post_p=0x7fffc0c0, gimple_test_f=0xaff86b
, fallback=0) at ../../gcc/gimplify.c:9323
#14 0x00b038ea in gimplify_stmt (stmt_p=0x7fffc238,
seq_p=0x7fffc2a8) at ../../gcc/gimplify.c:5551
#15 0x00af159f in gimplify_and_add (t=0x76a69e10,
seq_p=0x7fffc2a8) at ../../gcc/gimplify.c:410
#16 0x00af15d8 in gimplify_and_return_first (t=0x76a69e10,
seq_p=0x7fffc2a8) at ../../gcc/gimplify.c:422
#17 0x00b0d0c8 in gimplify_omp_parallel (expr_p=0x7fffc528,
pre_p=0x7fffc5f8) at ../../gcc/gimplify.c:7551
#18 0x00b1685d in gimplify_expr (expr_p=0x7fffc528,
pre_p=0x7fffc5f8, post_p=0x7fffc3b0, gimple_test_f=0xaff86b
, fallback=0) at ../../gcc/gimplify.c:9573
#19 0x00b038ea in gimplify_stmt (stmt_p=0x7fffc528,
seq_p=0x7fffc5f8) at ../../gcc/gimplify.c:5551
#20 0x00af159f in gimplify_and_add (t=0x76a6f410,
seq_p=0x7fffc5f8) at ../../gcc/gimplify.c:410
#21 0x00af15d8 in gimplify_and_return_first (t=0x76a6f410,
seq_p=0x7fffc5f8) at ../../gcc/gimplify.c:422
#22 0x00b11303 in gimplify_omp_for (expr_p=0x7fffc998,
pre_p=0x7fffc9d0) at ../../gcc/gimplify.c:8199
#23 0x00b168a7 in gimplify_expr (expr_p=0x7fffc998,
pre_p=0x7fffc9d0, post_p=0x7fffc820, gimple_test_f=0xaff86b
, fallback=0) at ../../gcc/gimplify.c:9589
#24 0x00b038ea in gimplify_stmt (stmt_p=0x7fffc998,
seq_p=0x7fffc9d0) at ../../gcc/gimplify.c:5551
#25 0x00af159f in gimplify_and_add (t=0x768d9ca8,
seq_p=0x7fffc9d0) at ../../gcc/gimplify.c:410
#26 0x00b12cfe in gimplify_omp_workshare (expr_p=0x76a69e60,
pre_p=0x7fffcc98) at ../../gcc/gimplify.c:8478
#27 0x00b169e2 in gimplify_expr (expr_p=0x76a69e60,
pre_p=0x7fffcc98, post_p=0x7fffcaf0, gimple_test_f=0xaff86b
, fallback=0) at ../../gcc/gimplify.c:9625
#28 0x00b038ea in gimplify_stmt (stmt_p=0x76a69e60,
seq_p=0x7fffcc98) at ../../gcc/gimplify.c:5551
#29 0x00af357d in gimplify_bind_expr (expr_p=0x7fffcf58,
pre_p=0x7fffcfd0) at ../../gcc/gimplify.c:1123
#30 0x00b15865 in gimplify_expr (expr_p=0x7fffcf58,
pre_p=0x7fffcfd0, post_p=0x7fffcde0, gimple_test_f=0xaff86b
, fallback=0) at ../../gcc/gimplify.c:9323
#31 0x00b038ea in gimplify_stmt (stmt_p=0x7fffcf58,
seq_p=0x7fffcfd0) at ../../gcc/gimplify.c:5551
#32 0x00af159f in gimplify_and_add (t=0x76a69e40,
seq_p=0x7fffcfd0) at ../../gcc/gimplify.c:410
#33 0x00af15d8 in gimplify_and_return_first (t=0x76a69e40,
seq_p=0x7fffcfd0) at ../../gcc/gimplify.c:422
#34 0x00b12bb0 in gimplify_omp_workshare (expr_p=0x76a6c4f0,
pre_p=0x7fffd518) at ../../gcc/gimplify.c:8449
#35 0x00b169e2 in gimplify_expr (expr_p=0x76a6c4f0,
pre_p=0x7fffd518, post_p=0x7fffd0f0, gimple_test_f=0xaff86b

[Bug fortran/67170] PRE can't hoist out a readonly argument

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67170

--- Comment #1 from Martin Liška mliska at suse dot cz ---
Created attachment 36160
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36160action=edit
Test case

[Bug fortran/67170] New: PRE can't hoist out a readonly argument

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67170

Bug ID: 67170
   Summary: PRE can't hoist out a readonly argument
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz
  Target Milestone: ---

In attached Fortran source file, we are unable to hoist out the single function
argument. The argument is reloaded at the end of loop.

Thanks,
Martin

[Bug lto/63968] [5 Regression] 175.vpr from cpu2000 fails to build with LTO

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63968

--- Comment #5 from Martin Liška mliska at suse dot cz ---
On 11/20/2014 11:43 PM, hubicka at gcc dot gnu.org wrote:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63968

 Jan Hubicka hubicka at gcc dot gnu.org changed:

 What|Removed |Added
 
   CC||hubicka at gcc dot gnu.org

 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org ---
/* If we wanted to, we could actually do a real increase by redeleting and
   inserting. However, this would require O (log n) time. So just bail out
   for now.  */
if (fibheap_comp_data (heap, key, data, node)  0)
  return NULL;

 It is clearly bug in the old implementation.  Increase is quite easy to 
 handle:
 you just remember the increased value and if your find_min returns one where
 value has increased, just re-insert it and get another minimum.

 This requires to store two keys, that is probably not good for generic
 template.  Perhaps bb-reorder can just see if it is increasing and perform
 delete+insert. Its loop is not perofrmance critical (inliner did so and it was
 too slow in that case)


Hi.

My suggested patch adds support for increase operation, where I delete 
and insert new key. As such usage is quite rare, I hope suggested 
approach fits? One can choose between: 'replace_key' and 'decrease', 
where the second one contains assert that new key is really smaller.

Thanks,
Martin

[Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587

--- Comment #12 from Martin Liška mliska at suse dot cz ---
On 10/24/2014 10:44 AM, rguenther at suse dot de wrote:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587

 --- Comment #10 from rguenther at suse dot de rguenther at suse dot de ---
 On Thu, 23 Oct 2014, marxin at gcc dot gnu.org wrote:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587

 --- Comment #8 from Martin Liška marxin at gcc dot gnu.org ---
 I added assert to cgraphunit.c (expand_thunk):1547:

/* Build call to the function being thunked.  */
if (!VOID_TYPE_P (restype))
  {
if (DECL_BY_REFERENCE (resdecl))
  restmp = gimple_fold_indirect_ref (resdecl);
else if (!is_gimple_reg_type (restype))
  {
restmp = resdecl;
gcc_assert (TREE_CODE (restmp) == VAR_DECL);
add_local_decl (cfun, restmp);
BLOCK_VARS (DECL_INITIAL (current_function_decl)) = restmp;
  }
else
  restmp = create_tmp_reg (restype, retval);
  }

 It's triggered quite often, one example of a thunk created by IPA ICF:

 Well, the bug is the add_local_decl being called with a RESULT_DECL.
 Thus you should try placing an assert into add_local_decl instead
 (need to move it out-of-line for that).

You are right, it would be good to place assert to add_local_decl function,
attachment contains suggested patch
that I will regtest.

Problematic is that one would like to place assert to function.h, but gengtype
does not include tree.h
for gencondmd.c:

In file included from build/gencondmd.c:5:0:
../../gcc/function.h: In function ‘void add_local_decl(function*, tree)’:
../../gcc/function.h:674:27: error: ‘TREE_CODE’ was not declared in this scope
gcc_assert (TREE_CODE (d) == VAR_DECL);

Is it acceptable to put the implementation to function.c?

Thanks,
Martin


 std::basic_streambuf_CharT, _Traits::pos_type std::basic_streambuf_CharT,
 _Traits::seekpos(std::basic_streambuf_CharT, _Traits::pos_type,
 std::ios_base::openmode) [with _CharT = char; _Traits = 
 std::char_traitschar;
 std::basic_streambuf_CharT, _Traits::pos_type = std::fpos__mbstate_t;
 std::ios_base::openmode = std::_Ios_Openmode] (struct basic_streambuf * const
 this, struct pos_type D.23077, openmode D.23078)
 {
struct pos_type retval;

bb 2:
retval = std::basic_streambufwchar_t::seekpos (this_2(D), D.23077,
 _3(D)); [tail call]
return retval;

 }

 where std::basic_streambuf_CharT, _Traits::pos_type is:
   result_decl 0x74eec708 D.39821
  type record_type 0x759c2150 pos_type sizes-gimplified asm_written 
 used
 needs-constructing type_1 type_5 TI
  size integer_cst 0x76c2fe40 constant 128
  unit size integer_cst 0x76c2fe58 constant 16
  align 64 symtab -164402368 alias set -1 canonical type 
 0x7614adc8
  fields field_decl 0x751cd850 _M_off type integer_type
 0x7678c738 streamoff
  used private nonlocal decl_3 DI file
 /home/marxin/Programming/gcc/objdir/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/postypes.h
 line 115 col 33
  size integer_cst 0x76c2fdf8 constant 64
  unit size integer_cst 0x76c2fe10 constant 8
  align 64 offset_align 128
  offset integer_cst 0x76c2fe28 constant 0
  bit offset integer_cst 0x76c2fe70 constant 0 context
 record_type 0x7614adc8 fpos chain field_decl 0x751cd8e8 _M_state
 context namespace_decl 0x76c4c098 std
  full-name std::basic_streambufchar::pos_type
  needs-constructor X() has-type-conversion X(constX) this=(X)
 n_parents=0 use_template=1 interface-unknown
  pointer_to_this pointer_type 0x75224e70 chain type_decl
 0x76146da8 fpos
  ignored TI file
 /home/marxin/Programming/gcc/objdir/x86_64-unknown-linux-gnu/libstdc++-v3/include/streambuf
 line 602 col 7 size integer_cst 0x76c2fe40 128 unit size integer_cst
 0x76c2fe58 16
  align 64 context function_decl 0x75797948 seekoff

 Is there a bug in expand_thunk or do I miss something?
 Thanks,
 Martin

[Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587

--- Comment #9 from Martin Liška mliska at suse dot cz ---
On 10/20/2014 09:48 AM, rguenther at suse dot de wrote:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587

 --- Comment #4 from rguenther at suse dot de rguenther at suse dot de ---
 On Sun, 19 Oct 2014, mliska at suse dot cz wrote:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587

 --- Comment #2 from Martin Liška mliska at suse dot cz ---
 Following two functions are merged:
 static boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type
 boost::log::make_output_actorActorTLeftExprT, RightT,
 ValueT::make(ActorTLeftExprT, RightT) [with ActorT = boost::actor;
 LeftExprT = int; RightT = boost::log::attribute_actorint,
 boost::log::value_extractor, void, boost::actor; ValueT = int;
 boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type =
 boost::actorboost::log::attribute_output_terminalboost::actorint,
 boost::log::to_log_fun ] (struct actor left, struct attribute_actor  
 right)


 static boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type
 boost::log::make_output_actorActorTLeftExprT, RightT,
 ValueT::make(ActorTLeftExprT, RightT) [with ActorT = boost::actor;
 LeftExprT = int; RightT = boost::log::attribute_actor{anonymous}::my_class,
 boost::log::value_extractor, void, boost::actor; ValueT = int;
 boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type =
 boost::actorboost::log::attribute_output_terminalboost::actorint,
 boost::log::to_log_fun ] (struct actor left, struct attribute_actor  
 right)

 with following body:
 {
struct type D.3826;
struct to_log_fun D.3825;
struct attribute_name D.3824;
int SR.9;
struct actor left;

bb 2:
left = left;
SR.9_4 = MEM[(struct attribute_terminal *)right_2(D)];
MEM[(struct attribute_name *)D.3824] = SR.9_4;
boost::log::attribute_output_terminalboost::actorint,
 boost::log::to_log_fun::attribute_output_terminalint (D.3826, left, 
 D.3824,
 D.3825, 0);
D.3826 ={v} {CLOBBER};
return;

 }



 As I was debugging ao_ref_alias_sets, there's MEM_REF where we have different
 template arguments: attribute_actorint,... vs.
 attribute_actor{anonymous}::my_class,
 What do you think Richard about these record_types from alias set 
 perspective:

 (gdb) p debug_tree(t1)
   mem_ref 0x76ab4000
  type integer_type 0x76c33690 int public type_6 SI
  size integer_cst 0x76c51048 constant 32
  unit size integer_cst 0x76c51060 constant 4
  align 32 symtab 0 alias set 4 canonical type 0x76c33690 
 precision
 32 min integer_cst 0x76c51000 -2147483648 max integer_cst 
 0x76c51018
 2147483647
  pointer_to_this pointer_type 0x76c55738

  arg 0 ssa_name 0x76aae678
  type reference_type 0x76e20d20 type record_type 0x76de7dc8
 attribute_actor
  unsigned DI
  size integer_cst 0x76c2fdf8 constant 64
  unit size integer_cst 0x76c2fe10 constant 8
  align 64 symtab 0 alias set 7 canonical type 0x76e20d20
  visited var parm_decl 0x76e1eb00 rightdef_stmt GIMPLE_NOP

  version 2
  ptr-info 0x76a7e3d8
  arg 1 integer_cst 0x76a4ee28 type pointer_type 0x76dbfa80
 constant 0
 $1 = void
 (gdb) p debug_tree(t2)
   mem_ref 0x76aa1ac8
  type integer_type 0x76c33690 int public type_6 SI
  size integer_cst 0x76c51048 constant 32
  unit size integer_cst 0x76c51060 constant 4
  align 32 symtab 0 alias set 4 canonical type 0x76c33690 
 precision
 32 min integer_cst 0x76c51000 -2147483648 max integer_cst 
 0x76c51018
 2147483647
  pointer_to_this pointer_type 0x76c55738

  arg 0 ssa_name 0x76a77dc8
  type reference_type 0x76e20540 type record_type 0x76ddd888
 attribute_actor
  unsigned DI
  size integer_cst 0x76c2fdf8 constant 64
  unit size integer_cst 0x76c2fe10 constant 8
  align 64 symtab 0 alias set 7 canonical type 0x76e20540
  visited var parm_decl 0x76e1ea00 rightdef_stmt GIMPLE_NOP

  version 2
  ptr-info 0x76a7e300
  arg 1 integer_cst 0x76a4ee28 type pointer_type 0x76dbfa80
 constant 0

 these types are called for alias_set comparison, with following record_types:
 (gdb) p debug_tree((tree_node*)0x76de7dc8)
   record_type 0x76de7dc8 attribute_actor needs-constructing type_5 
 type_6
 SI
  size integer_cst 0x76c51048 type integer_type 0x76c33150
 bitsizetype constant 32
  unit size integer_cst 0x76c51060 type integer_type 0x76c330a8
 sizetype constant 4
  align 32 symtab 0 alias set 17 canonical type 0x76de7dc8
  fields field_decl 0x76de4ed8 D.2798
  type record_type 0x76dddb28 actor needs-constructing type_5 
 type_6
 SI size integer_cst

[Bug ipa/63580] [5 Regression] ICE : error: invalid argument to gimple call

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63580

--- Comment #3 from Martin Liška mliska at suse dot cz ---
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63580

 Richard Biener rguenth at gcc dot gnu.org changed:

 What|Removed |Added
 
   Status|UNCONFIRMED |NEW
 Last reconfirmed||2014-10-20
   Ever confirmed|0   |1

 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
 You miss to mark p1 addressable in the alias decl (that is, copy
 TREE_ADDRESSABLE).


Do you mean following change:

@@ -2334,6 +2334,14 @@ cgraph_node::create_wrapper (cgraph_node *target)

  cgraph_edge *e = create_edge (target, NULL, 0, CGRAPH_FREQ_BASE);

+  tree arguments = DECL_ARGUMENTS (decl);
+
+  while (arguments)
+{
+  TREE_ADDRESSABLE (arguments) = false;
+  arguments = TREE_CHAIN (arguments);
+}
+
  expand_thunk (false, true);
  e-call_stmt_cannot_inline_p = true;

Thanks,
Martin

[Bug tree-optimization/63595] [5.0 Regression] Segmentation faults inside kernel

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63595

--- Comment #6 from Martin Liška mliska at suse dot cz ---
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63595

 --- Comment #5 from Pat Haugen pthaugen at gcc dot gnu.org ---
 Created attachment 33796
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33796action=edit
 preprocessed source from 254.gap

 CPU2000 benchmark 254.gap started miscomparing with r216305 also. Attaching
 preprocessed source as another example that gets miscompiled. Compile options
 used 'gcc -m64 -O2 -mcpu=power7'. In this example, function 'FunOnRight' gets
 redirected to 'FunOnLeft' (after initial test where the two functions have
 differing error strings). But the last stmt in the functions which compute the
 return value are not equivalent and therefor shouldn't be commoned.

  From list.i:

 FunOnRight()
  ...
  hdRes = ((*TabProd[(((long)(hdPnt)  1) ? 1 :
 ((hdPnt)-type))][(((long)(hdElm)  1) ? 1 :
 ((hdElm)-type))])((hdPnt),(hdElm)));


 FunOnLeft()
  ...
  hdRes = ((*TabProd[(((long)(hdElm)  1) ? 1 :
 ((hdElm)-type))][(((long)(hdPnt)  1) ? 1 :
 ((hdPnt)-type))])((hdElm),(hdPnt)));


 Note the swapping of 'hdPnt' and 'hdElm' references.


There's patch I've been testing:

diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index d1238a4..7456fec 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -869,6 +869,12 @@ sem_function::compare_phi_node (basic_block bb1, 
basic_block bb2)
phi1 = gsi_stmt (si1);
phi2 = gsi_stmt (si2);

+  tree phi_result1 = gimple_phi_result (phi1);
+  tree phi_result2 = gimple_phi_result (phi2);
+
+  if (!m_checker-compare_operand (phi_result1, phi_result2))
+return return_false_with_msg (PHI results are different);
+
size1 = gimple_phi_num_args (phi1);
size2 = gimple_phi_num_args (phi2);


Martin

[Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63587

--- Comment #2 from Martin Liška mliska at suse dot cz ---
Following two functions are merged:
static boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type
boost::log::make_output_actorActorTLeftExprT, RightT,
ValueT::make(ActorTLeftExprT, RightT) [with ActorT = boost::actor;
LeftExprT = int; RightT = boost::log::attribute_actorint,
boost::log::value_extractor, void, boost::actor; ValueT = int;
boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type =
boost::actorboost::log::attribute_output_terminalboost::actorint,
boost::log::to_log_fun ] (struct actor left, struct attribute_actor  right)


static boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type
boost::log::make_output_actorActorTLeftExprT, RightT,
ValueT::make(ActorTLeftExprT, RightT) [with ActorT = boost::actor;
LeftExprT = int; RightT = boost::log::attribute_actor{anonymous}::my_class,
boost::log::value_extractor, void, boost::actor; ValueT = int;
boost::log::make_output_actorActorTLeftExprT, RightT, ValueT::type =
boost::actorboost::log::attribute_output_terminalboost::actorint,
boost::log::to_log_fun ] (struct actor left, struct attribute_actor  right)

with following body:
{
  struct type D.3826;
  struct to_log_fun D.3825;
  struct attribute_name D.3824;
  int SR.9;
  struct actor left;

  bb 2:
  left = left;
  SR.9_4 = MEM[(struct attribute_terminal *)right_2(D)];
  MEM[(struct attribute_name *)D.3824] = SR.9_4;
  boost::log::attribute_output_terminalboost::actorint,
boost::log::to_log_fun::attribute_output_terminalint (D.3826, left, D.3824,
D.3825, 0);
  D.3826 ={v} {CLOBBER};
  return;

}



As I was debugging ao_ref_alias_sets, there's MEM_REF where we have different
template arguments: attribute_actorint,... vs.
attribute_actor{anonymous}::my_class,
What do you think Richard about these record_types from alias set perspective:

(gdb) p debug_tree(t1)
 mem_ref 0x76ab4000
type integer_type 0x76c33690 int public type_6 SI
size integer_cst 0x76c51048 constant 32
unit size integer_cst 0x76c51060 constant 4
align 32 symtab 0 alias set 4 canonical type 0x76c33690 precision
32 min integer_cst 0x76c51000 -2147483648 max integer_cst 0x76c51018
2147483647
pointer_to_this pointer_type 0x76c55738

arg 0 ssa_name 0x76aae678
type reference_type 0x76e20d20 type record_type 0x76de7dc8
attribute_actor
unsigned DI
size integer_cst 0x76c2fdf8 constant 64
unit size integer_cst 0x76c2fe10 constant 8
align 64 symtab 0 alias set 7 canonical type 0x76e20d20
visited var parm_decl 0x76e1eb00 rightdef_stmt GIMPLE_NOP

version 2
ptr-info 0x76a7e3d8
arg 1 integer_cst 0x76a4ee28 type pointer_type 0x76dbfa80
constant 0
$1 = void
(gdb) p debug_tree(t2)
 mem_ref 0x76aa1ac8
type integer_type 0x76c33690 int public type_6 SI
size integer_cst 0x76c51048 constant 32
unit size integer_cst 0x76c51060 constant 4
align 32 symtab 0 alias set 4 canonical type 0x76c33690 precision
32 min integer_cst 0x76c51000 -2147483648 max integer_cst 0x76c51018
2147483647
pointer_to_this pointer_type 0x76c55738

arg 0 ssa_name 0x76a77dc8
type reference_type 0x76e20540 type record_type 0x76ddd888
attribute_actor
unsigned DI
size integer_cst 0x76c2fdf8 constant 64
unit size integer_cst 0x76c2fe10 constant 8
align 64 symtab 0 alias set 7 canonical type 0x76e20540
visited var parm_decl 0x76e1ea00 rightdef_stmt GIMPLE_NOP

version 2
ptr-info 0x76a7e300
arg 1 integer_cst 0x76a4ee28 type pointer_type 0x76dbfa80
constant 0

these types are called for alias_set comparison, with following record_types:
(gdb) p debug_tree((tree_node*)0x76de7dc8)
 record_type 0x76de7dc8 attribute_actor needs-constructing type_5 type_6
SI
size integer_cst 0x76c51048 type integer_type 0x76c33150
bitsizetype constant 32
unit size integer_cst 0x76c51060 type integer_type 0x76c330a8
sizetype constant 4
align 32 symtab 0 alias set 17 canonical type 0x76de7dc8
fields field_decl 0x76de4ed8 D.2798
type record_type 0x76dddb28 actor needs-constructing type_5 type_6
SI size integer_cst 0x76c51048 32 unit size integer_cst 0x76c51060
4
align 32 symtab 0 alias set 15 canonical type 0x76dddb28 fields
field_decl 0x76de01c8 proto_expr_ context namespace_decl 0x76d8d2f8
boost
full-name struct boost::actorboost::log::attribute_terminal
needs-constructor X() X(constX) this=(X) n_parents=0
use_template=1 interface-unknown
pointer_to_this pointer_type 0x76e03930 reference_to_this
reference_type 0x76dff0a8 chain type_decl 0x76de0098

[Bug ipa/63576] [5 Regression] ICE : in ipa_merge_profiles, at ipa-utils.c:540 during Firefox LTO/PGO build

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576

--- Comment #1 from Martin Liška mliska at suse dot cz ---
Do you have Honza an idea how to handle correctly situation, where ipa_profile
is called before IPA ICF and we mark speculative an edge in:

#0  cgraph_edge::make_speculative (this=this@entry=0x769e8c98,
n2=0x76933468, direct_count=1776, direct_frequency=optimized out) at
../../gcc/cgraph.c:1027
#1  0x00844d6f in ipa_profile () at ../../gcc/ipa-profile.c:641
#2  (anonymous namespace)::pass_ipa_profile::execute (this=optimized out) at
../../gcc/ipa-profile.c:742
#3  0x0091bee2 in execute_one_pass (pass=pass@entry=0x1bc76b0) at
../../gcc/passes.c:2155
#4  0x0091cbc2 in execute_ipa_pass_list (pass=0x1bc76b0) at
../../gcc/passes.c:2545
#5  0x005e222b in do_whole_program_analysis () at
../../gcc/lto/lto.c:3253
#6  0x005e25e6 in lto_main () at ../../gcc/lto/lto.c:3431
#7  0x009d48f2 in compile_file () at ../../gcc/toplev.c:555
#8  0x009d6bdf in do_compile () at ../../gcc/toplev.c:1977
#9  toplev_main (argc=28, argv=0x1ba4970) at ../../gcc/toplev.c:2053
#10 0x012140dc in main (argc=26, argv=0x7fffdd38) at
../../gcc/main.c:36

Thank you,
Martin

[Bug debug/63572] [5 Regression] ICF breaks user debugging experience

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

--- Comment #6 from Martin Liška mliska at suse dot cz ---
There's how gold's ICF works for test attached by Jakub:

gcc --version:
gcc version 5.0.0 20141016 (experimental) (GCC) 

ld --version:
GNU gold (GNU Binutils 2.24.51.20141010) 1.11

$ gcc icf-gdb.c -c -g --function-sections
$ gcc icf-gdb.o -o a.out -Wl,--icf=all,--print-icf-sections
...
ld: ICF folding section '.text.f2' in file 'icf-gdb.o' into '.text.f1' in file
'icf-gdb.o'
...

dwarfdump a.ou shows:
 10x0059DW_TAG_subprogram
  DW_AT_name  f1
  DW_AT_decl_file 0x0001
/home/marxin/Programming/testcases/icf-gdb.c
  DW_AT_decl_line 0x0005
  DW_AT_prototypedyes(1)
  DW_AT_type  0x0052
  DW_AT_low_pc0x00400546
  DW_AT_high_pc   offset-from-lowpc115
  DW_AT_frame_baselen 0x0001: 9c:
DW_OP_call_frame_cfa
  DW_AT_GNU_all_call_sitesyes(1)
  DW_AT_sibling   0x00e2


and:
 10x00e8DW_TAG_subprogram
  DW_AT_name  f2
  DW_AT_decl_file 0x0001
/home/marxin/Programming/testcases/icf-gdb.c
  DW_AT_decl_line 0x0015
  DW_AT_prototypedyes(1)
  DW_AT_type  0x0052
  DW_AT_low_pc0x00400546
  DW_AT_high_pc   offset-from-lowpc115
  DW_AT_frame_baselen 0x0001: 9c:
DW_OP_call_frame_cfa
  DW_AT_GNU_all_call_sitesyes(1)
  DW_AT_sibling   0x0171

If I tried to put breakpoint in GDB to f2, breakpoint is triggered 4 times with
back-trace from all functions f3-f6.
Example:
#0  f1 (x=0x7fffda10) at icf-gdb.c:24
#1  0x004005d1 in f3 (x=0x7fffda10) at icf-gdb.c:33
#2  0x00400657 in main () at icf-gdb.c:44


Maybe I miss something, but gold also does not support correct DWARF merging.
I will create issue for gold.

Martin

[Bug debug/63572] [5 Regression] ICF breaks user debugging experience

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

--- Comment #8 from Martin Liška mliska at suse dot cz ---
Created attachment 33747
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33747action=edit
Gold ICF dwarfdump

[Bug go/63560] New: __go_set_defer_retaddr shouldn't be split by IPA split

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63560

Bug ID: 63560
   Summary: __go_set_defer_retaddr shouldn't be split by IPA split
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: mliska at suse dot cz
CC: cmang at google dot com, hubicka at ucw dot cz, iant at 
google dot com,
mliska at suse dot cz

Starting from r216305, IPA ICF can unify functions that will change decision
made by IPA inline. As a result, we end up with split function:


Not working version:
bytes_test.$thunk0 (struct
{
  struct __go_descriptor * fn;
} * __go_thunk_parameter)
{
  bool _3;

  bb 2:
  # DEBUG $ret49 = 0
  _3 = __go_set_defer_retaddr (retaddr);
  if (_3 != 0)
goto bb 4 (retaddr);
  else
goto bb 3;

  bb 3:
  bytes_test.$thunk0.part.15 (__go_thunk_parameter_4(D));

retaddr:
  # DEBUG $ret49 = 0
  return 0;

}

I discussed this stuff with Ian and Honza and the agreement is that we should
not split functions decorated with noinline attribute. Honza will come up with
a patch.

Thank you,
Martin

[Bug ipa/63566] New: [5 Regression] i686 bootstrap fails: ICE RTL flag check: INSN_UID used with unexpected rtx code 'set' in INSN_UID, at rtl.h:1326

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63566

Bug ID: 63566
   Summary: [5 Regression] i686 bootstrap fails: ICE RTL flag
check: INSN_UID used with unexpected rtx code 'set' in
INSN_UID, at rtl.h:1326
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz

After introduction of IPA ICF in r216305, i686 fails to bootstrap.
I reduced IPA ICF to just merge a single function:
Semantic equality hit:void mark_oprs_set(rtx_insn*)-void
make_set_regs_unavailable(rtx_insn*).

With this change applied, stage2 compiler is miscompiled and following error
occurs:
../../../libgcc/config/libbid/bid_round.c: In function ‘__bid_round64_2_18’:
../../../libgcc/config/libbid/bid_round.c:210:1: internal compiler error: RTL
flag check: INSN_UID used with unexpected rtx code 'set' in INSN_UID, at
rtl.h:1326

Comparison of object files (compiled with stage1 compiler with and w/o
-fipa-icf) show following difference:

With IPA ICF (cprop.o):
contains .set
_ZL25make_set_regs_unavailableP8rtx_insn,_ZL13mark_oprs_setP8rtx_insn

and the only difference is in usage of the function (IPA ICF):
.L633:
subl$12, %esp
.cfi_def_cfa_offset 108
pushl%ebx
.cfi_def_cfa_offset 112
call_ZL25make_set_regs_unavailableP8rtx_insn
movzwl(%ebx), %edx
addl$16, %esp
.cfi_def_cfa_offset 96
cmpb$0, rtx_length(%edx)
jne.L643

while original usage (-fno-ipa-icf) contains:
.L644:
movl%ebx, %eax
call_ZL25make_set_regs_unavailableP8rtx_insn
movzwl(%ebx), %edx
cmpb$0, rtx_length(%edx)
jne.L654

I am not familiar with x86 calling conventions for aliases, but I suspect this
chunk of code.

Does anyone can see a problem in this chunk?
Thank you for help,
Martin

[Bug ipa/63566] [5 Regression] i686 bootstrap fails: ICE RTL flag check: INSN_UID used with unexpected rtx code 'set' in INSN_UID, at rtl.h:1326

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63566

--- Comment #1 from Martin Liška mliska at suse dot cz ---
Created attachment 33738
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33738action=edit
Patch that enables just a single function merge operation.

[Bug ipa/63566] [5 Regression] i686 bootstrap fails: ICE RTL flag check: INSN_UID used with unexpected rtx code 'set' in INSN_UID, at rtl.h:1326

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63566

--- Comment #3 from Martin Liška mliska at suse dot cz ---
Created attachment 33740
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33740action=edit
object file created w/ IPA ICF

[Bug ipa/63566] [5 Regression] i686 bootstrap fails: ICE RTL flag check: INSN_UID used with unexpected rtx code 'set' in INSN_UID, at rtl.h:1326

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63566

--- Comment #2 from Martin Liška mliska at suse dot cz ---
Created attachment 33739
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33739action=edit
object file created w/o IPA ICF

[Bug middle-end/63544] New: [5 Regression] hash_map ends in an infinite loop if overwritten mark_empty uses a different value than 0

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63544

Bug ID: 63544
   Summary: [5 Regression]  hash_map ends in an infinite loop if
overwritten mark_empty uses a different value than 0
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz
CC: tbsaunde at gcc dot gnu.org

Hello.

With following patch applied:
diff --git a/gcc/value-prof.c b/gcc/value-prof.c
index 37710ca..43900c1 100644
--- a/gcc/value-prof.c
+++ b/gcc/value-prof.c
@@ -1240,9 +1240,9 @@ struct profile_id_traits : default_hashmap_traits
   return e.m_key == UINT_MAX;
 }

-  templatetypename T static bool is_empty (T e) { return e.m_key == 0; }
+  templatetypename T static bool is_empty (T e) { return e.m_key ==
UINT_MAX - 1; }
   templatetypename T static void mark_deleted (T e) { e.m_key = UINT_MAX; }
-  templatetypename T static void mark_empty (T e) { e.m_key = 0; }
+  templatetypename T static void mark_empty (T e) { e.m_key = UINT_MAX - 1;
}
 };

 static hash_mapunsigned int, cgraph_node *, profile_id_traits *

I configured GCC: ../configure --enable-languages=c,c++ --disable-libsanitizer
--disable-multilib
and run: make profiledbootstrap

After stage1 compiler is built, I loop in:
#0  hash_mapunsigned int, cgraph_node*,
profile_id_traits::hash_entry::is_deleted (e=...) at ../../gcc/hash-map.h:132
#1  0x00f4bb14 in is_deleted_helperhash_mapunsigned int,
cgraph_node*, profile_id_traits::hash_entry, hash_mapunsigned int,
cgraph_node*, profile_id_traits::hash_entry, false::call (v=...) at
../../gcc/hash-table.h:392
#2  0x00f4b375 in hash_tablehash_mapunsigned int, cgraph_node*,
profile_id_traits::hash_entry, xcallocator, true::is_deleted (v=...) at
../../gcc/hash-table.h:1170
#3  0x00f4b0cc in hash_tablehash_mapunsigned int, cgraph_node*,
profile_id_traits::hash_entry, xcallocator, true::find_with_hash
(this=0x29c7e00, comparable=@0x7f3fd57042e0: 108032747, hash=108032747) at
../../gcc/hash-table.h:1435
#4  0x00f4a662 in hash_mapunsigned int, cgraph_node*,
profile_id_traits::get (this=0x29c7e00, k=@0x7f3fd57042e0: 108032747)
at ../../gcc/hash-map.h:220
#5  0x00f4810c in init_node_map (local=true) at
../../gcc/value-prof.c:1280
#6  0x00d3b298 in tree_profiling () at ../../gcc/tree-profile.c:584
#7  0x00d3b75d in (anonymous namespace)::pass_ipa_tree_profile::execute
(this=0x29d5e90) at ../../gcc/tree-profile.c:709
#8  0x00b643cb in execute_one_pass (pass=0x29d5e90) at
../../gcc/passes.c:2151
#9  0x00b6517b in execute_ipa_pass_list (pass=0x29d5e90) at
../../gcc/passes.c:2541
#10 0x00804083 in ipa_passes () at ../../gcc/cgraphunit.c:2012
#11 0x00804422 in symbol_table::compile (this=0x7f3fd56f5000) at
../../gcc/cgraphunit.c:2131
#12 0x0080475c in symbol_table::finalize_compilation_unit
(this=0x7f3fd56f5000) at ../../gcc/cgraphunit.c:2284
#13 0x00663d4a in c_write_global_declarations () at
../../gcc/c/c-decl.c:10633
#14 0x00c5b98a in compile_file () at ../../gcc/toplev.c:565
#15 0x00c5dc88 in do_compile () at ../../gcc/toplev.c:1973
#16 0x00c5ddf3 in toplev_main (argc=26, argv=0x7fff49285938) at
../../gcc/toplev.c:2049
#17 0x01523bb0 in main (argc=26, argv=0x7fff49285938) at
../../gcc/main.c:36

Thank you for help,
Martin

[Bug middle-end/63376] [5.0 Regression] ICE: in operator[], at vec.h:736 compiling team.c

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63376

Martin Liška mliska at suse dot cz changed:

   What|Removed |Added

 CC||mliska at suse dot cz

--- Comment #6 from Martin Liška mliska at suse dot cz ---
Fixed in r216110.

[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409

--- Comment #10 from Martin Liška mliska at suse dot cz ---
Fixed in r215967.

[Bug ipa/63470] New: [5 Regression] lto1: internal compiler error: in estimate_edge_growth, at ipa-inline.h:308

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470

Bug ID: 63470
   Summary: [5 Regression] lto1: internal compiler error: in
estimate_edge_growth, at ipa-inline.h:308
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz
CC: hubicka at ucw dot cz

Starting from r215794 Firefox produces following error in WPA with -flto and
--enable-checking=all:

lto1: internal compiler error: in estimate_edge_growth, at ipa-inline.h:308
0x7d7fc1 estimate_edge_growth
../../gcc/ipa-inline.h:307
0x7d7fc1 estimate_size_after_inlining(cgraph_node*, cgraph_edge*)
../../gcc/ipa-inline-analysis.c:3817
0xf388d1 caller_growth_limits
../../gcc/ipa-inline.c:186
0xf388d1 can_inline_edge_p
../../gcc/ipa-inline.c:363
0xf3acdd update_callee_keys
../../gcc/ipa-inline.c:1236
0xf3c9a6 inline_small_functions
../../gcc/ipa-inline.c:1818
0xf3c9a6 ipa_inline
../../gcc/ipa-inline.c:2182
0xf3c9a6 execute
../../gcc/ipa-inline.c:2542

Edge:
caller:
_ZNK12SkRefCntBase16internal_disposeEv/14636955 (internal_dispose)
@0x7f9c1a33d178
  Type: function definition analyzed
  Visibility: virtual
  next sharing asm name: 14636951
  References: 
  Referring: 
  Read from file:
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/toolkit/library/build/../../../gfx/2d/Unified_cpp_gfx_2d0.o
  Function internal_dispose/14636955 is inline copy in __base_dtor /13594851
  Clone of _ZNK12SkRefCntBase16internal_disposeEv/14636951
  Availability: local
  First run: 0
  Function flags: local
  Called by: _ZNK12SkRefCntBase5unrefEv.part.40/14636954 (inlined)
(indirect_inlining) (0.02 per call) 
  Calls: _ZN13SkGPipeCanvasD0Ev/13594853 (indirect_inlining) (0.01 per call) 
callee:
_ZN13SkGPipeCanvasD0Ev/13594853 (__deleting_dtor ) @0x7f9c1575d8d0
  Type: function definition analyzed
  Visibility: prevailing_def_ironly virtual
  Address is taken.
  References: 
  Referring: _ZTV13SkGPipeCanvas/13595722
(addr)_ZNK12SkRefCntBase16internal_disposeEv/14605659 (addr)
(speculative)_ZNK12SkRefCntBase16internal_disposeEv/14614102 (addr)
(speculative)_ZNK12SkRefCntBase16internal_disposeEv/14636951 (addr)
(speculative)
  Read from file:
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/toolkit/library/build/../../../gfx/skia/Unified_cpp_gfx_skia20.o
  Availability: available
  First run: 0
  Function flags:
  Called by: _ZNK12SkRefCntBase16internal_disposeEv/14636955
(indirect_inlining) (0.01 per call)
_ZNK12SkRefCntBase16internal_disposeEv/14636951 (speculative)
(indirect_inlining) (0.03 per call)
_ZNK12SkRefCntBase16internal_disposeEv/14614102 (speculative)
(indirect_inlining) (0.08 per call)
_ZNK12SkRefCntBase16internal_disposeEv/14605659 (speculative)
(indirect_inlining) (0.08 per call) 
  Calls: moz_free/1431 (1.00 per call) _ZN13SkGPipeCanvasD1Ev/13594852 (1.00
per call) 

Thanks,
Martin

[Bug pch/63429] [Regression 5] Cannot build compiler with --enable-gather-detailed-mem-stats

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63429

Martin Liška mliska at suse dot cz changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Martin Liška mliska at suse dot cz ---
Works for me.

[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409

--- Comment #7 from Martin Liška mliska at suse dot cz ---
Yeah, sorry for wrong dg argument. There's new version that should work
correctly. If not regression will be seen, I will commit the patch.

[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409

--- Comment #8 from Martin Liška mliska at suse dot cz ---
Created attachment 33653
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33653action=edit
Fix patch2

[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409

--- Comment #3 from Martin Liška mliska at suse dot cz ---
Created attachment 33643
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33643action=edit
Fix patch

[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409

--- Comment #4 from Martin Liška mliska at suse dot cz ---
Can you please verify for me that the following patch fixes the problem for
your arch?

Thanks,
Martin

[Bug middle-end/35545] tracer pass is run too late

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545

--- Comment #25 from Martin Liška mliska at suse dot cz ---
SPEC CPU numbers (--size=train, --iterations=3):

First 3 columns present time (where smaller means faster) and for binary size
the same.

++--++---+-+-++
|| gcc-O3   | gcc-O3-fdo | gcc-O3-tracer | gcc-O3_SIZE |
gcc-O3-fdo_SIZE | gcc-O3-tracer_SIZE |
++--++---+-+-++
| GemsFDTD   | 100.00 % |96.00 % |   95.56 % |100.00 % |   
101.14 % |   109.58 % |
| hmmer  | 100.00 % |97.44 % |   97.14 % |100.00 % |
73.94 % |   105.71 % |
| sphinx3| 100.00 % |95.42 % |   97.76 % |100.00 % |
88.44 % |   104.29 % |
| milc   | 100.00 % |99.35 % |  101.13 % |100.00 % |   
101.48 % |   103.98 % |
| cactusADM  | 100.00 % |99.97 % |   99.46 % |100.00 % |
76.84 % |   106.86 % |
| tonto  | 100.00 % |94.72 % |   98.04 % |100.00 % |
80.27 % |   107.15 % |
| bwaves | 100.00 % |   104.47 % |  101.77 % |100.00 % |   
100.33 % |   103.21 % |
| lbm| 100.00 % |96.65 % |   98.49 % |100.00 % |   
106.25 % |   102.04 % |
| wrf| 100.00 % |61.39 % |   65.49 % |100.00 % |
64.51 % |   112.40 % |
| bzip2  | 100.00 % |93.79 % |  100.10 % |100.00 % |   
115.36 % |   108.78 % |
| leslie3d   | 100.00 % |96.52 % |   98.73 % |100.00 % |   
100.24 % |   107.03 % |
| gromacs| 100.00 % |97.12 % |  100.75 % |100.00 % |
77.08 % |   104.82 % |
| sjeng  | 100.00 % |98.77 % |   99.80 % |100.00 % |
84.01 % |   101.87 % |
| calculix   | 100.00 % |   101.55 % |  100.28 % |100.00 % |
79.58 % |   104.36 % |
| astar  | 100.00 % |   101.70 % |   97.19 % |100.00 % |   
102.73 % |   101.95 % |
| zeusmp | 100.00 % |98.79 % |  101.00 % |100.00 % |   
113.59 % |   102.36 % |
| povray | 100.00 % |89.17 % |  100.35 % |100.00 % |
83.61 % |   105.07 % |
| omnetpp| 100.00 % |88.23 % |  102.54 % |100.00 % |
90.70 % |   102.47 % |
| mcf| 100.00 % |95.92 % |  100.03 % |100.00 % |   
124.69 % |   102.62 % |
| gcc| 100.00 % |97.04 % |   98.88 % |100.00 % |   
108.29 % |   101.24 % |
| h264ref| 100.00 % |94.61 % |  100.58 % |100.00 % |
88.25 % |   105.93 % |
| perlbench  | 100.00 % |98.90 % |  100.46 % |100.00 % |   
106.21 % |   106.23 % |
| xalancbmk  | 100.00 % |75.17 % |   82.56 % |100.00 % |
87.10 % |   103.41 % |
| namd   | 100.00 % |99.48 % |  100.59 % |100.00 % |
88.25 % |   100.74 % |
| gamess | 100.00 % |   130.31 % |  131.62 % |100.00 % |
96.00 % |   101.59 % |
| libquantum | 100.00 % |97.04 % |   98.98 % |100.00 % |
68.74 % |   104.55 % |
| soplex | 100.00 % |96.15 % |  100.92 % |100.00 % |
87.04 % |   100.96 % |
| gobmk  | 100.00 % |91.22 % |  104.56 % |100.00 % |
84.16 % |   106.75 % |
++--++---+-+-++
| AVG| 100.00 % |95.96 % |   99.10 % |100.00 % |
92.10 % |   104.57 % |
++--++---+-+-++

Martin

[Bug pch/63429] New: [Regression 5] Cannot build compiler with --enable-gather-detailed-mem-stats

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63429

Bug ID: 63429
   Summary: [Regression 5] Cannot build compiler with
--enable-gather-detailed-mem-stats
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz

Error:
g++ -c   -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H
-DGENERATOR_FILE -I. -Ibuild -I../../gcc -I../../gcc/build
-I../../gcc/../include  -I../../gcc/../libcpp/include  \
-o build/gencondmd.o build/gencondmd.c
In file included from ../../gcc/hash-table.h:199:0,
 from ../../gcc/hash-set.h:24,
 from ../../gcc/function.h:24,
 from build/gencondmd.c:25:
../../gcc/ggc.h:165:59: error: default argument given for parameter 3 of ‘void*
ggc_realloc(void*, size_t, const char*, int, const char*)’ [-fpermissive]
 extern void *ggc_realloc (void *, size_t CXX_MEM_STAT_INFO);
   ^
In file included from ../../gcc/rtl.h:28:0,
 from build/gencondmd.c:23:
../../gcc/vec.h:54:16: note: previous specification in ‘void*
ggc_realloc(void*, size_t, const char*, int, const char*)’ here
   extern void *ggc_realloc (void *, size_t CXX_MEM_STAT_INFO);
^
In file included from ../../gcc/hash-table.h:199:0,
 from ../../gcc/hash-set.h:24,
 from ../../gcc/function.h:24,
 from build/gencondmd.c:25:
../../gcc/ggc.h:165:59: error: default argument given for parameter 4 of ‘void*
ggc_realloc(void*, size_t, const char*, int, const char*)’ [-fpermissive]
 extern void *ggc_realloc (void *, size_t CXX_MEM_STAT_INFO);
   ^
In file included from ../../gcc/rtl.h:28:0,
 from build/gencondmd.c:23:
../../gcc/vec.h:54:16: note: previous specification in ‘void*
ggc_realloc(void*, size_t, const char*, int, const char*)’ here
   extern void *ggc_realloc (void *, size_t CXX_MEM_STAT_INFO);
^
In file included from ../../gcc/hash-table.h:199:0,
 from ../../gcc/hash-set.h:24,
 from ../../gcc/function.h:24,
 from build/gencondmd.c:25:
../../gcc/ggc.h:165:59: error: default argument given for parameter 5 of ‘void*
ggc_realloc(void*, size_t, const char*, int, const char*)’ [-fpermissive]
 extern void *ggc_realloc (void *, size_t CXX_MEM_STAT_INFO);
   ^
In file included from ../../gcc/rtl.h:28:0,
 from build/gencondmd.c:23:
../../gcc/vec.h:54:16: note: previous specification in ‘void*
ggc_realloc(void*, size_t, const char*, int, const char*)’ here
   extern void *ggc_realloc (void *, size_t CXX_MEM_STAT_INFO);

Started with r214834.

Thanks,
Martin

[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409

Martin Liška mliska at suse dot cz changed:

   What|Removed |Added

 CC||mliska at suse dot cz

--- Comment #2 from Martin Liška mliska at suse dot cz ---
Mine. I will prepare the testcase to resolve missing references.

[Bug middle-end/35545] tracer pass is run too late

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545

--- Comment #24 from Martin Liška mliska at suse dot cz ---
Hello Honza. I've been working on SPEC numbers, I will send it this evening.

[Bug c/63344] [5 Regression] Linux (makeallyes config) compilation error: error: apic_numachip causes a section type conflict with numachip_system

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63344

--- Comment #6 from Martin Liška mliska at suse dot cz ---
(In reply to Andi Kleen from comment #5)
 I posted a patch here
 http://permalink.gmane.org/gmane.linux.kernel/1793662
 
 BTW actually I don't agree that the bug is valid. We should probably relax
 the LTO checking to match what the linker does (which does not error out for
 this case).

I've just tested Andi's patch and works for me. To be more precise, the kernel
has been compiled without LTO.

[Bug c/63344] [5 Regression] Linux (makeallyes config) compilation error: error: apic_numachip causes a section type conflict with numachip_system

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63344

--- Comment #4 from Martin Liška mliska at suse dot cz ---
(In reply to Andi Kleen from comment #3)
 Yes it's a kernel bug. I hit it earlier too.
 
 const always needs to go into separate sections.
 const __read_mostly is also meaningless.

Is there any existing bug in Linux Kernel that can be linked to this thread?

[Bug c/63344] New: [5 Regression] Linux (makeallyes config) compilation error: error: apic_numachip causes a section type conflict with numachip_system

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63344

Bug ID: 63344
   Summary: [5 Regression] Linux (makeallyes config) compilation
error: error: apic_numachip causes a section type
conflict with numachip_system
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz
CC: hubicka at ucw dot cz

During testing of latest compiler, I've encountered an error in Linux kernel:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/x86/kernel/apic/apic_numachip.c?id=refs/tags/next-20140923

arch/x86/kernel/apic/apic_numachip.c:33:12: error: numachip_system causes a
section type conflict with apic_numachip
 static int numachip_system __read_mostly;
^
arch/x86/kernel/apic/apic_numachip.c:205:26: note: 'apic_numachip' was declared
here
 static const struct apic apic_numachip __refconst = {

There's a testcase reduced by creduce:
$ cat testcase.ii

struct apic {
  int *name
} numachip_system __attribute__((__section__(.data..read_mostly)));
static const struct apic apic_numachip
__attribute__((__section__(.data..read_mostly)));
static const struct apic apic_numachip
__attribute__((__section__())) = {.name = };

$ gcc testcase.i -S
/home/marxin/Programming/testcases/kernel_numa/testcase.i:6:26: error:
apic_numachip causes a section type conflict with numachip_system

The problem started with: r211363

Older gcc produces:
/home/marxin/Programming/testcases/kernel_numa/testcase.i:3:1: warning: no
semicolon at end of struct or union [enabled by default]
 } numachip_system __attribute__((__section__(.data..read_mostly)));
 ^
/home/marxin/Programming/testcases/kernel_numa/testcase.i:7:5: warning:
initialization from incompatible pointer type [enabled by default]
 __attribute__((__section__())) = {.name = };
 ^
/home/marxin/Programming/testcases/kernel_numa/testcase.i:7:5: warning: (near
initialization for ‘apic_numachip.name’) [enabled by default]

I am not familiar with section attribute magic, but it looks like a regression.

Thank you,
Martin

[Bug ipa/63298] [5 Regression] internal compiler error: in types_same_for_odr, at ipa-devirt.c:449 with LTO

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63298

Martin Liška mliska at suse dot cz changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Martin Liška mliska at suse dot cz ---
Fixed.

[Bug ipa/63270] [5 Regression] internal compiler error: in odr_types_equivalent_p, at ipa-devirt.c:1075

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63270

--- Comment #3 from Martin Liška mliska at suse dot cz ---
The problem does not occur in mainline any more, starting with: r215328.

[Bug ipa/63298] New: [5 Regression] internal compiler error: in types_same_for_odr, at ipa-devirt.c:449 with LTO

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63298

Bug ID: 63298
   Summary: [5 Regression] internal compiler error: in
types_same_for_odr, at ipa-devirt.c:449 with LTO
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz

After fixed issued PR63270 with r215328, it looks there's a new ICE in Chrome
with LTO:

bt
lto1: internal compiler error: in types_same_for_odr, at ipa-devirt.c:449
0x6f9eba types_same_for_odr(tree_node const*, tree_node const*)
../../gcc/ipa-devirt.c:449
0x6fa0a2 odr_subtypes_equivalent_p
../../gcc/ipa-devirt.c:535
0x6fb5db odr_types_equivalent_p
../../gcc/ipa-devirt.c:1026
0x6fbd37 add_type_duplicate
../../gcc/ipa-devirt.c:1191
0x6fc143 get_odr_type(tree_node*, bool)
../../gcc/ipa-devirt.c:1339
0x6fc472 register_odr_type(tree_node*)
../../gcc/ipa-devirt.c:1407
0x56c15e lto_read_decls
../../gcc/lto/lto.c:1918
0x56d068 lto_file_finalize
../../gcc/lto/lto.c:2212
0x56d068 lto_create_files_from_ids
../../gcc/lto/lto.c:
0x56d068 lto_file_read
../../gcc/lto/lto.c:2263
0x56d068 read_cgraph_and_symbols
../../gcc/lto/lto.c:2966
0x56d068 lto_main()
../../gcc/lto/lto.c:3420


where type1 at ipa-devirt.c:449 is:
 array_type 0x7fffcb788bd0 UVersionInfo
type integer_type 0x76e1c888 uint8_t public unsigned string-flag QI
size integer_cst 0x76c2ec48 constant 8
unit size integer_cst 0x76c2ec60 constant 1
align 8 symtab 0 alias set 0 canonical type 0x76c323f0 precision 8
min integer_cst 0x76c2ec78 0 max integer_cst 0x76c2ec18 255
pointer_to_this pointer_type 0x76379690 reference_to_this
reference_type 0x7fffe1ad93f0
SI
size integer_cst 0x76c2ed98 type integer_type 0x76c32150
bitsizetype constant 32
unit size integer_cst 0x76c2edb0 type integer_type 0x76c320a8
sizetype constant 4
align 8 symtab 0 alias set 0 canonical type 0x769b6f18
domain integer_type 0x76da1000
type integer_type 0x76c320a8 sizetype public unsigned DI
size integer_cst 0x76c2eb58 constant 64
unit size integer_cst 0x76c2eb70 constant 8
align 64 symtab 0 alias set -1 canonical type 0x76c32888
precision 64 min integer_cst 0x76c2eb88 0 max integer_cst 0x76c3e460
18446744073709551615
pointer_to_this pointer_type 0x7fffef83abd0
DI size integer_cst 0x76c2eb58 64 unit size integer_cst
0x76c2eb70 8
align 64 symtab 0 alias set 0 canonical type 0x76c327e0 precision
64 min integer_cst 0x76c2eb88 0 max integer_cst 0x76d89d20 3
pointer_to_this pointer_type 0x7fffcb78ef18

Unfortunately, it looks very hard to isolate a few objects (libraries) for
Chrome, my current minimum command-line is still following:

c++  -fPIC -pie -L. -O2 -flto=7 -Wl,--start-group  
obj/chrome/app/chrome_initial.chrome_main.oobj/content/libcontent_worker.a
obj/content/libcontent_app_both.a   
obj/third_party/WebKit/Source/platform/libblink_platform.a   
obj/third_party/ots/libots.a   
obj/third_party/WebKit/Source/web/libblink_web.a  
obj/third_party/WebKit/Source/core/libwebcore_remaining.a -Wl,--end-group
--verbose --save-temps


Why necessary, I will try to isolate the bunch of translation units.

Thanks,
Martin

[Bug ipa/63298] [5 Regression] internal compiler error: in types_same_for_odr, at ipa-devirt.c:449 with LTO

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63298

--- Comment #3 from Martin Liška mliska at suse dot cz ---
Works for me ;)

[Bug ipa/63270] New: [5 Regression] internal compiler error: in odr_types_equivalent_p, at ipa-devirt.c:1075

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63270

Bug ID: 63270
   Summary: [5 Regression] internal compiler error: in
odr_types_equivalent_p, at ipa-devirt.c:1075
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz

Created attachment 33494
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33494action=edit
runtime.ii

Following code (creduce chunks from Chromium browser) throws an internal
compiler error:

$ g++ -c preparser.ii -flto -O2 -o preparser.o
$ g++ -c runtime.ii -flto -O2 -o runtime.o
$ g++ -flto -O2 runtime.o preparser.o

lto1: internal compiler error: in odr_types_equivalent_p, at ipa-devirt.c:1075
0x703d06 odr_types_equivalent_p
../../gcc/ipa-devirt.c:1075
0x70231b odr_subtypes_equivalent_p
../../gcc/ipa-devirt.c:511
0x703092 odr_types_equivalent_p
../../gcc/ipa-devirt.c:826
0x70231b odr_subtypes_equivalent_p
../../gcc/ipa-devirt.c:511
0x70386a odr_types_equivalent_p
../../gcc/ipa-devirt.c:983
0x703e5e add_type_duplicate
../../gcc/ipa-devirt.c:1116
0x70426a get_odr_type(tree_node*, bool)
../../gcc/ipa-devirt.c:1264
0x704599 register_odr_type(tree_node*)
../../gcc/ipa-devirt.c:1332
0x575e04 lto_read_decls
../../gcc/lto/lto.c:1918
0x576745 lto_file_finalize
../../gcc/lto/lto.c:2212
0x576745 lto_create_files_from_ids
../../gcc/lto/lto.c:
0x576745 lto_file_read
../../gcc/lto/lto.c:2263
0x576745 read_cgraph_and_symbols
../../gcc/lto/lto.c:2966
0x576745 lto_main()
../../gcc/lto/lto.c:3420

gcc --version:
gcc (GCC) 5.0.0 20140915 (experimental)

Thanks,
Martin

[Bug ipa/63270] [5 Regression] internal compiler error: in odr_types_equivalent_p, at ipa-devirt.c:1075

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63270

--- Comment #1 from Martin Liška mliska at suse dot cz ---
Created attachment 33495
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33495action=edit
preparser.ii

[Bug target/61974] New: error: ‘ASM_WEAKEN_DECL’ was not declared in this scope

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61974

Bug ID: 61974
   Summary: error: ‘ASM_WEAKEN_DECL’ was not declared in this
scope
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz
  Host: x86_64
Target: rs6000-ibm-aix4.3

Attempting to build cross compiler for rs6000 target:

./configure --enable-languages=c --target=rs6000-ibm-aix4.3

Error:
g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I../../gcc/../libcpp/include  -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace  
 -o rs6000.o -MT rs6000.o -MMD -MP -MF ./.deps/rs6000.TPo
../../gcc/config/rs6000/rs6000.c
../../gcc/config/rs6000/rs6000.c: In function ‘bool
rs6000_declare_alias(symtab_node*, void*)’:
../../gcc/config/rs6000/rs6000.c:29612:50: error: ‘ASM_WEAKEN_DECL’ was not
declared in this scope
  ASM_WEAKEN_DECL (data-file, n-decl, name, NULL);

[Bug target/55143] vms-c.o:(.toc+0x0): undefined reference to `c_default_pointer_mode' (building cc1plus)

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55143

Martin Liška mliska at suse dot cz changed:

   What|Removed |Added

 CC||mliska at suse dot cz

--- Comment #1 from Martin Liška mliska at suse dot cz ---
Problem is still present in 4.10.0.

[Bug ipa/61842] [4.10 Regression]: Firefox start-up SEGFAULT with LTO and O3

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61842

--- Comment #2 from Martin Liška mliska at suse dot cz ---
Issue is not related to GCC, same error can be seen without LTO and even with
older GCC. When I tried older Firefox (May 2014), latest GCC looks fine.

[Bug ipa/61842] [4.10 Regression]: Firefox start-up SEGFAULT with LTO and O3

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61842

Martin Liška mliska at suse dot cz changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Martin Liška mliska at suse dot cz ---
Invalid.

[Bug ipa/61842] New: [4.10 Regression]: Firefox start-up SEGFAULT with LTO and O3

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61842

Bug ID: 61842
   Summary: [4.10 Regression]: Firefox start-up SEGFAULT with LTO
and O3
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz

Firefox: https://github.com/marxin/gecko-dev/tree/lto-stable (revision:
88a7edf3bab2d1b9a2c140c1f36217f4fbdd1e03)
GCC revision: r212778 with applied
(https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00929.html)

error:
*** Error in
`/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/firefox':
double free or corruption (fasttop): 0x00587930 ***
=== Backtrace: =
/lib64/libc.so.6(+0x7410f)[0x7737d10f]
/lib64/libc.so.6(+0x7996e)[0x7738296e]
/lib64/libc.so.6(+0x7a647)[0x77383647]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0xa7120f)[0x72d0120f]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0xaf2e54)[0x72d82e54]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0xb54ebc)[0x72de4ebc]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0xb55d81)[0x72de5d81]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0xac9d77)[0x72d59d77]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0x244b27f)[0x746db27f]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0x244b415)[0x746db415]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(XRE_main+0x203c)[0x746e221c]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/firefox[0x4074af]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/firefox[0x402fc8]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7732abe5]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/firefox[0x403051]

BT:
Program received signal SIGABRT, Aborted.
0x7733e849 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x7733e849 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x7733fcd8 in __GI_abort () at abort.c:89
#2  0x7737d114 in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x77473220 *** Error in `%s': %s: 0x%s ***\n)
at ../sysdeps/posix/libc_fatal.c:175
#3  0x7738296e in malloc_printerr (action=3, str=0x77473408 double
free or corruption (fasttop), ptr=optimized out)
at malloc.c:4916
#4  0x77383647 in _int_free (av=optimized out, p=0x587920,
have_lock=0) at malloc.c:3772
#5  0x72d0120f in operator delete () at
../../../dist/include/mozilla/mozalloc.h:225
#6  __base_dtor (this=synthetic pointer) at
../../../dist/include/nsAutoPtr.h:73
#7  nsPrefBranch::RemoveObserver (this=optimized out, aDomain=optimized
out, aObserver=optimized out)
at
/home/marxin/Programming/gecko-dev/modules/libpref/src/nsPrefBranch.cpp:658
#8  0x72d82e54 in nsSocketTransportService::Shutdown (this=0x586690)
at
/home/marxin/Programming/gecko-dev/netwerk/base/src/nsSocketTransportService2.cpp:537
#9  0x72de4ebc in nsIOService::SetOffline (this=0x582260,
offline=optimized out)
at /home/marxin/Programming/gecko-dev/netwerk/base/src/nsIOService.cpp:748
#10 0x72de5d81 in nsIOService::Observe (this=0x582260,
subject=optimized out, topic=optimized out, 
data=0x756bd7a0 nsXREDirProvider::DoShutdown()::kShutdownPersist
ushutdown-persist)
at /home/marxin/Programming/gecko-dev/netwerk/base/src/nsIOService.cpp:918
#11 0x72d59d77 in NotifyObservers (
someData=0x756bd7a0 nsXREDirProvider::DoShutdown()::kShutdownPersist
ushutdown-persist, 
aTopic=0x7542f899 profile-change-net-teardown, aSubject=0x0,
this=optimized out)
at /home/marxin/Programming/gecko-dev/xpcom/ds/nsObserverList.cpp:96
#12 nsObserverService::NotifyObservers (this=0x57b8f0, aSubject=0x0,
aTopic=0x7542f899 profile-change-net-teardown, 
someData=0x756bd7a0 nsXREDirProvider::DoShutdown()::kShutdownPersist
ushutdown-persist)
at /home/marxin/Programming/gecko-dev/xpcom/ds/nsObserverService.cpp:303
#13 0x746db27f in _ZN16nsXREDirProvider10DoShutdownEv.part.17
(this=0x7fffc220)
at /home/marxin/Programming/gecko-dev/toolkit/xre/nsXREDirProvider.cpp:853
#14 0x746db415 in DoShutdown (this=optimized out) at
/home/marxin/Programming/gecko-dev/toolkit/xre/nsAppRunner.cpp:1204
#15 __base_dtor  (this=0x50bdc0) at
/home/marxin/Programming/gecko-dev/toolkit/xre/nsAppRunner.cpp:1196
#16 0x746e221c in XRE_main

[Bug ipa/61842] [4.10 Regression]: Firefox start-up SEGFAULT with LTO and O3

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61842

--- Comment #1 from Martin Liška mliska at suse dot cz ---
I've just double checked that I have the same issue with -O2.

[Bug c++/61691] New: [4.10 Regression] invalid use of incomplete type in Firefox

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61691

Bug ID: 61691
   Summary: [4.10 Regression] invalid use of incomplete type in
Firefox
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz

Created attachment 33065
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33065action=edit
reduced.ii

Starting from r212174, following error can be encountered in reduced test case
coming from latest Firefox:

g++ -std=gnu++0x -O2 -c /tmp/reduced.ii 
/tmp/reduced.ii: In instantiation of ‘nsRefPtrT::~nsRefPtr() [with T =
mozilla::dom::AudioNode]’:
/tmp/reduced.ii:38:7:   required from here
/tmp/reduced.ii:9:7: error: invalid use of incomplete type ‘class
mozilla::dom::AudioNode’
   mRawPtr-Release();
   ^
/tmp/reduced.ii:25:7: note: forward declaration of ‘class
mozilla::dom::AudioNode’
 class AudioNode;

I also attached original preprocessed file from Firefox.

Thanks,
Martin

[Bug c++/61691] [4.10 Regression] invalid use of incomplete type in Firefox

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61691

--- Comment #1 from Martin Liška mliska at suse dot cz ---
Created attachment 33066
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33066action=edit
MediaPipeline.ii

[Bug middle-end/61573] [4.10 Regression] ICE: Segmentation fault building Linux kernel

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61573

Martin Liška mliska at suse dot cz changed:

   What|Removed |Added

 CC||mliska at suse dot cz

--- Comment #3 from Martin Liška mliska at suse dot cz ---
Bug introduced in r211363.

[Bug middle-end/61573] [4.10 Regression] ICE: Segmentation fault building Linux kernel

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61573

--- Comment #4 from Martin Liška mliska at suse dot cz ---
fndecl deletion place:

Old value = (tree) 0x76d4a700
New value = (tree) 0xa5a5a5a5a5a5a5a5
memset () at ../sysdeps/x86_64/memset.S:90
90../sysdeps/x86_64/memset.S: No such file or directory.
(gdb) bt
#0  memset () at ../sysdeps/x86_64/memset.S:90
#1  0x006478e7 in ggc_free (p=optimized out) at
../../gcc/ggc-page.c:1592
#2  0x006bdeac in release_function_body (decl=0x76d4a800) at
../../gcc/cgraph.c:1704
#3  0x006be030 in cgraph_release_function_body (node=0x76d69170) at
../../gcc/cgraph.c:1729
#4  0x006be431 in cgraph_remove_node (node=0x76d69170) at
../../gcc/cgraph.c:1814
#5  0x0055f7aa in duplicate_decls (newdecl=0x76d4a800,
olddecl=0x76d4a700) at ../../gcc/c/c-decl.c:2584
#6  0x0056008e in pushdecl (x=0x76d4a800) at
../../gcc/c/c-decl.c:2725
#7  0x00564673 in start_decl (declarator=0x1876620,
declspecs=0x1876590, initialized=false, attributes=0x0)
at ../../gcc/c/c-decl.c:4277
#8  0x005cd865 in c_parser_declaration_or_fndef
(parser=parser@entry=0x76d67000, fndef_ok=false, fndef_ok@entry=true, 
static_assert_ok=static_assert_ok@entry=true, empty_ok=empty_ok@entry=true,
nested=nested@entry=false, 
start_attr_ok=start_attr_ok@entry=true,
objc_foreach_object_declaration=objc_foreach_object_declaration@entry=0x0, 
omp_declare_simd_clauses=..., omp_declare_simd_clauses@entry=...) at
../../gcc/c/c-parser.c:1798
#9  0x005d26b6 in c_parser_external_declaration (parser=0x76d67000)
at ../../gcc/c/c-parser.c:1400
#10 0x005d316a in c_parser_translation_unit (parser=0x76d67000) at
../../gcc/c/c-parser.c:1287
#11 c_parse_file () at ../../gcc/c/c-parser.c:14082
#12 0x006277c5 in c_common_parse_file () at
../../gcc/c-family/c-opts.c:1067
#13 0x00a09f32 in compile_file () at ../../gcc/toplev.c:548
#14 0x00a0bee5 in do_compile () at ../../gcc/toplev.c:1918
#15 toplev_main (argc=14, argv=0x7fffd9b8) at ../../gcc/toplev.c:1994
#16 0x76e4ebe5 in __libc_start_main (main=0x554f50 main(int, char**),
argc=14, argv=0x7fffd9b8, init=optimized out, 
fini=optimized out, rtld_fini=optimized out, stack_end=0x7fffd9a8)
at libc-start.c:269
#17 0x00554fd1 in _start () at ../sysdeps/x86_64/start.S:122

[Bug ipa/61462] [4.10 Regression] ICE in ipa-prop.c:2562 caused by missing edge gimple call stmt

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61462

Martin Liška mliska at suse dot cz changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Martin Liška mliska at suse dot cz ---
Fixed.

[Bug lto/60449] Merging function DECLs discards leaf attribute which causes cfg verifier to fail

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60449

Martin Liška mliska at suse dot cz changed:

   What|Removed |Added

 CC||mliska at suse dot cz

--- Comment #13 from Martin Liška mliska at suse dot cz ---
Same problem can be seen in Chromium. The final binary contains about ~3500
usages of a function with different DECL attributes. Problematic is just one
function:

sigaction/538949 (sigaction) @0x7f0fb8916450
 DECL_ATTR:
sigaction/718813 (sigaction) @0x7f0fb7db58a0
 DECL_ATTR: __leaf__ , __nothrow__ 

Thus, preserving both variants of the function would not increase symtab
significantly.

[Bug middle-end/61462] New: ICE in ipa-prop.c:2562 caused by missing edge gimple call stmt

[mliska at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61462

Bug ID: 61462
   Summary: ICE in ipa-prop.c:2562 caused by missing edge gimple
call stmt
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz

Created attachment 32914
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32914action=edit
Suggested patch

Problem was met during run of gimp with following flags:
'-flto -fdump-ipa-all'.

backtrace:
lto1: internal compiler error: Segmentation fault
0x8321af crash_signal
../../gcc/toplev.c:337
0x6e5297 gimple_location
../../gcc/gimple.h:1499
0x6ebe06 ipa_make_edge_direct_to_target(cgraph_edge*, tree_node*)
../../gcc/ipa-prop.c:2562
0xc923a1 ipcp_discover_new_direct_edges
../../gcc/ipa-cp.c:2373
0xc923a1 create_specialized_node
../../gcc/ipa-cp.c:2821
0xc96b7f decide_whether_version_node
../../gcc/ipa-cp.c:3557
0xc96b7f ipcp_decision_stage
../../gcc/ipa-cp.c:3669
0xc96b7f ipcp_driver
../../gcc/ipa-cp.c:3715
0xc96b7f execute
../../gcc/ipa-cp.c:3807

Problem is that in LTO there's a virtual 'constprop' clone created by ipa-cp.
An edge for this newly created node has e-stmt == NULL.

Introduced in 210657.

[Bug c++/61076] New: [4.10 Regression] ICE SEGFAULT in bb_predicate tree-if-conv.c:149

[mliska at suse dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61076

Bug ID: 61076
   Summary: [4.10 Regression] ICE SEGFAULT in bb_predicate
tree-if-conv.c:149
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz

Created attachment 32744
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32744action=edit
qtwebkit_reduced.cpp

BT:
qtwebkit_reduced.cpp:59:6: internal compiler error: Segmentation fault
 int *F::allocateBlock(int p1) { m_blocks.add(); }
  ^
0xb77b7f crash_signal
../../gcc/toplev.c:337
0xbcf54f bb_predicate
../../gcc/tree-if-conv.c:149
0xbcf54f is_predicated
../../gcc/tree-if-conv.c:275
0xbcf54f is_cond_scalar_reduction
../../gcc/tree-if-conv.c:1442
0xbcf54f predicate_scalar_phi
../../gcc/tree-if-conv.c:1583
0xbcf54f predicate_all_scalar_phis
../../gcc/tree-if-conv.c:1637
0xbcf54f combine_blocks
../../gcc/tree-if-conv.c:1954
0xbcf54f tree_if_conversion
../../gcc/tree-if-conv.c:2108
0xbcf54f execute
../../gcc/tree-if-conv.c:2187

To reproduce:
$ g++ -O3 qtwebkit_reduced.cpp

First occurred in: revision 209972

[Bug c++/61076] [4.10 Regression] ICE SEGFAULT in bb_predicate tree-if-conv.c:149

[mliska at suse dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61076

Martin Liška mliska at suse dot cz changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Martin Liška mliska at suse dot cz ---
Duplicate of added.

*** This bug has been marked as a duplicate of bug 61042 ***

[Bug tree-optimization/61042] [4.10 Regression] ICE on valid code at -O3 on x86_64-linux-gnu

[mliska at suse dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61042

Martin Liška mliska at suse dot cz changed:

   What|Removed |Added

 CC||mliska at suse dot cz

--- Comment #2 from Martin Liška mliska at suse dot cz ---
*** Bug 61076 has been marked as a duplicate of this bug. ***

[Bug c++/61012] New: lto1: errors during merging of translation units (error: variable ‘link’ redeclared as function)

[mliska at suse dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61012

Bug ID: 61012
   Summary: lto1: errors during merging of translation units
(error: variable ‘link’ redeclared as function)
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz

$ cat a.c
struct s
{
  int a;
  int b;
};

static struct s link = { 1, 2 };

int foo()
{
  return link.a;
}

$ cat b.c
#include unistd.h

int main()
{
  int r = link(aaa, bbb);

  return foo();
}

$ gcc a.c b.c -flto -O2

/usr/include/unistd.h:812:12: error: variable ‘link’ redeclared as function
 extern int link (const char *__from, const char *__to)
^
a.c:7:17: note: previously declared here
 static struct s link = { 1, 2 };
 ^
lto1: fatal error: errors during merging of translation units
compilation terminated.
lto-wrapper: gcc returned 1 exit status
/home/marxin/Programming/bin/gcc2/lib64/gcc/x86_64-unknown-linux-gnu/4.10.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
fatal error: lto-wrapper failed
collect2: error: ld returned 1 exit status

[Bug c++/60969] New: ICE in output_129 in MMXMOV of mode MODE_SF for march=pentium4

[mliska at suse dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969

Bug ID: 60969
   Summary: ICE in output_129 in MMXMOV of mode MODE_SF for
march=pentium4
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz

g++ -O2 pentium.cpp -c -ftree-vectorize -march=pentium4 -m32

BT:
#0  output_129 (operands=0x1413ac0 recog_data, insn=0x76e0d948) at
../../gcc/config/i386/i386.md:3177
#1  0x007805e2 in final_scan_insn (insn=insn@entry=0x76e0d948,
file=file@entry=0x14c7370, optimize_p=optimize_p@entry=2,
nopeepholes=nopeepholes@entry=0, seen=seen@entry=0x7fffd55c) at
../../gcc/final.c:2918
#2  0x00780ec7 in final (first=0x76dbc5c0, file=0x14c7370,
optimize_p=2) at ../../gcc/final.c:2023
#3  0x007810f6 in rest_of_handle_final () at ../../gcc/final.c:4427
#4  (anonymous namespace)::pass_final::execute (this=optimized out) at
../../gcc/final.c:4502
#5  0x008b3dba in execute_one_pass (pass=pass@entry=0x14a26c0) at
../../gcc/passes.c:2229
#6  0x008b4006 in execute_pass_list (pass=0x14a26c0) at
../../gcc/passes.c:2282
#7  0x008b4018 in execute_pass_list (pass=0x14a1940) at
../../gcc/passes.c:2283
#8  0x008b4018 in execute_pass_list (pass=0x14a0800) at
../../gcc/passes.c:2283
#9  0x006dccf6 in expand_function (node=node@entry=0x76dada40) at
../../gcc/cgraphunit.c:1774
#10 0x006de5ed in expand_all_functions () at
../../gcc/cgraphunit.c:1908
#11 compile () at ../../gcc/cgraphunit.c:2252
#12 0x006dea45 in finalize_compilation_unit () at
../../gcc/cgraphunit.c:2329
#13 0x005940ec in cp_write_global_declarations () at
../../gcc/cp/decl2.c:4611
#14 0x0094dd9d in compile_file () at ../../gcc/toplev.c:562
#15 0x0094f970 in do_compile () at ../../gcc/toplev.c:1914
#16 toplev_main (argc=19, argv=0x7fffd8c8) at ../../gcc/toplev.c:1990
#17 0x76e4ebe5 in __libc_start_main () from /lib64/libc.so.6
#18 0x0052c9a1 in _start () at ../sysdeps/x86_64/start.S:122

$ cat pentium4.cpp:

struct A
{
float f0, f1, f2, f3;
A() { }
A(float v0, float v1, float v2)
: f0(v0), f1(v1), f2(v2), f3(0.0f)
{
}
A method(A  a, float t)
{
return A (f0 + a.f0 * t, f1 + a.f1 * t, f2 + a.f2 * t);
}
};

A function(A  v1, A  v2, float t)
{
return v1.method (v2, t);
}

void Foo(A  a1, A  a2, A  a3, A  a4, int i1, int i2)
{
int MIN_TRIGGER = 7; // set below 7 and it compiles ok
A * x = new A[i1 * i2];
for (int i = 0; i  MIN_TRIGGER; i++) {
 A a1 = function (a1, a3, i / (float)i2);
 A a2 = function (a2, a4, i / (float)i2);
for (int j = 0; j  MIN_TRIGGER; j++)
x[i * i1 + j] = function (a1, a2, j / (float)i1);
}
}

[Bug lto/60820] [4.9/4.10 Regression] ice in ctor_for_folding, at varpool.c:291

[mliska at suse dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60820

--- Comment #6 from Martin Liška mliska at suse dot cz ---
Patch works for me for net-misc/nx package. Will you merge the patch to gcc-4.9
branch?

[Bug c++/60820] New: ice in ctor_for_folding, at varpool.c:291

[mliska at suse dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60820

Bug ID: 60820
   Summary: ice in ctor_for_folding, at varpool.c:291
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mliska at suse dot cz

I test gcc 4.9 on my x86_64 gentoo machine and ICE is encountered in
'net-misc/nx' package:

lto1: internal compiler error: in ctor_for_folding, at varpool.c:305
0xb4b0b6 ctor_for_folding(tree_node*)
../../gcc/varpool.c:292
0xb4b448 dump_varpool_node(_IO_FILE*, varpool_node*)
../../gcc/varpool.c:211
0x5bba6a dump_symtab(_IO_FILE*)
../../gcc/symtab.c:707
0x546084 do_whole_program_analysis
../../gcc/lto/lto.c:3248
0x546084 lto_main()
../../gcc/lto/lto.c:3422

decl:
 var_decl 0x7f574898be40 in6addr_any
type record_type 0x7f57488e4690 in6_addr readonly TI
size integer_cst 0x7f5748fc60a0 constant 128
unit size integer_cst 0x7f5748fc60c0 constant 16
align 32 symtab 0 alias set 0 canonical type 0x7f57488e4dc8
fields field_decl 0x7f57488ed980 __in6_u type union_type
0x7f57488e4d20
TI file /usr/include/netinet/in.h line 206 col 9 size integer_cst
0x7f5748fc60a0 128 unit size integer_cst 0x7f5748fc60c0 16
align 32 offset_align 128
offset integer_cst 0x7f5748fc6060 constant 0
bit offset integer_cst 0x7f5748fc60e0 constant 0 context
record_type 0x7f57488e4dc8 in6_addr context translation_unit_decl
0x7f57488ebb80 D.33269
pointer_to_this pointer_type 0x7f57488e4738
readonly public static weak TI file /usr/include/netinet/in.h line 214 col
30 size integer_cst 0x7f5748fc60a0 128 unit size integer_cst 0x7f5748fc60c0
16
align 32 context translation_unit_decl 0x7f5748977ac8 D.36198 attributes
tree_list 0x7f5748993190 initial constructor 0x7f5748974798

DECL_INITIAL(decl):
 constructor 0x7f5748974798
type record_type 0x7f57488e4690 in6_addr readonly TI
size integer_cst 0x7f5748fc60a0 constant 128
unit size integer_cst 0x7f5748fc60c0 constant 16
align 32 symtab 0 alias set 0 canonical type 0x7f57488e4dc8
fields field_decl 0x7f57488ed980 __in6_u type union_type
0x7f57488e4d20
TI file /usr/include/netinet/in.h line 206 col 9 size integer_cst
0x7f5748fc60a0 128 unit size integer_cst 0x7f5748fc60c0 16
align 32 offset_align 128
offset integer_cst 0x7f5748fc6060 constant 0
bit offset integer_cst 0x7f5748fc60e0 constant 0 context
record_type 0x7f57488e4dc8 in6_addr context translation_unit_decl
0x7f57488ebb80 D.33269
pointer_to_this pointer_type 0x7f57488e4738
constant static lngt 1 idx field_decl 0x7f57488ed980 __in6_u
val constructor 0x7f5748974768
type union_type 0x7f57488e4d20 TI size integer_cst 0x7f5748fc60a0
128 unit size integer_cst 0x7f5748fc60c0 16
align 32 symtab 0 alias set 0 canonical type 0x7f57488e4d20 fields
field_decl 0x7f57488ed7b8 __u6_addr8 context translation_unit_decl
0x7f57488ebb80 D.33269
chain type_decl 0x7f57488e2cf0 D.33550
constant static lngt 1
idx field_decl 0x7f57488ed7b8 __u6_addr8 type array_type
0x7f57488e4b28
TI file /usr/include/netinet/in.h line 201 col 10 size integer_cst
0x7f5748fc60a0 128 unit size integer_cst 0x7f5748fc60c0 16
align 8 offset_align 128 offset integer_cst 0x7f5748fc6060 0 bit
offset integer_cst 0x7f5748fc60e0 0 context union_type 0x7f57488e4d20 chain
field_decl 0x7f57488ed850 __u6_addr16
val constructor 0x7f5748974750 type array_type 0x7f57488e4b28
constant static lngt 16 idx integer_cst 0x7f5748fc60e0 0
val integer_cst 0x7f5748fc6220 constant 0
idx integer_cst 0x7f5748fc6680 constant 1 val integer_cst
0x7f5748fc6220 0
idx integer_cst 0x7f57490695c0 constant 2 val integer_cst
0x7f5748fc6220 0
idx integer_cst 0x7f5749139040 constant 3 val integer_cst
0x7f5748fc6220 0
idx integer_cst 0x7f57490695a0 constant 4 val integer_cst
0x7f5748fc6220 0
idx integer_cst 0x7f5749139180 constant 5 val integer_cst
0x7f5748fc6220 0
idx integer_cst 0x7f5749139240 constant 6 val integer_cst
0x7f5748fc6220 0
idx integer_cst 0x7f57491392e0 constant 7 val integer_cst
0x7f5748fc6220 0
idx integer_cst 0x7f5748fc61e0 constant 8 val integer_cst
0x7f5748fc6220 0
idx integer_cst 0x7f5749139400 constant 9 val integer_cst
0x7f5748fc6220 0
idx integer_cst 0x7f57491394a0 constant 10 val integer_cst
0x7f5748fc6220 0
idx integer_cst 0x7f5749139520 constant 11 val integer_cst
0x7f5748fc6220 0
idx integer_cst 0x7f57491395a0 constant 12 val integer_cst
0x7f5748fc6220 0
idx integer_cst 0x7f5749139640 constant 13 val integer_cst
0x7f5748fc6220 0
idx

[Bug c++/60820] ice in ctor_for_folding, at varpool.c:291

[mliska at suse dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60820

--- Comment #1 from Martin Liška mliska at suse dot cz ---
testcase:

cat a.c:
#include netinet/in.h
#include stdio.h

static const struct in6_addr local_in6addr_any = IN6ADDR_ANY_INIT;
#pragma weak in6addr_any = local_in6addr_any

__attribute__ ((used))
void foo()
{
  fprintf (stderr, v1: %p, v2: %p\n, local_in6addr_any, in6addr_any);
}

gcc -flto -O2 -c a.c -o a.o
gcc -flto -O2 -c a.c -o b.o
gcc -flto -O2 a.o b.o

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[mliska at suse dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

--- Comment #206 from Martin Liška mliska at suse dot cz ---
Firefox (and chromium) memory reports with -flto=9 and -O2; archive contains
also memory usage graph:

https://docs.google.com/file/d/0B0pisUJ80pO1bnV5V0RtWXJkaVU/edit

[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO

[mliska at suse dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375

--- Comment #207 from Martin Liška mliska at suse dot cz ---
Created attachment 32525
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32525action=edit
Memory usage graphs for -flto=9, -flto=4, -flto=1 with -O2