[PATCH] Fix dwarf2out ICE on zero sized array initializer (PR debug/85252)

2018-04-06 Thread Jakub Jelinek
Hi! As mentioned in the PR, we ICE on the following zero sized array initializers, while domain is non-NULL and TYPE_MIN_VALUE is size_int (0), TYPE_MAX_VALUE is NULL and not INTEGER_CST compare_tree_int assumes it is. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2018-04-

Re: [PATCH] Fix dwarf2out ICE on zero sized array initializer (PR debug/85252)

2018-04-06 Thread Richard Biener
On April 6, 2018 6:10:14 PM GMT+02:00, Jakub Jelinek wrote: >Hi! > >As mentioned in the PR, we ICE on the following zero sized array >initializers, while domain is non-NULL and TYPE_MIN_VALUE is size_int >(0), >TYPE_MAX_VALUE is NULL and not INTEGER_CST compare_tree_int assumes it >is. > >Bootstra

Re: [PATCH] Fix dwarf2out ICE on VEC_SERIES rtl (PR debug/83034)

2017-11-22 Thread Richard Biener
On Wed, 22 Nov 2017, Jakub Jelinek wrote: > Hi! > > On this testcase we get (vec_series (reg: ebp) (const_int 1)) > in NOTE_INSN_CALL_ARG_LOCATION because the vector isn't live anywhere else. > Right now we do not have a good story for providing values of optimized > out vectors, so just punting

[PATCH] Fix dwarf2out ICE on VEC_SERIES rtl (PR debug/83034)

2017-11-22 Thread Jakub Jelinek
Hi! On this testcase we get (vec_series (reg: ebp) (const_int 1)) in NOTE_INSN_CALL_ARG_LOCATION because the vector isn't live anywhere else. Right now we do not have a good story for providing values of optimized out vectors, so just punting on it like on other VEC_* codes is sufficient. For the

Re: [PATCH] Fix dwarf2out ICE with UNSPEC_GOTOFF (PR debug/82837)

2017-11-08 Thread Jeff Law
On 11/06/2017 02:35 PM, Jakub Jelinek wrote: > Hi! > > My recent changes to const_ok_for_output_1 to allow UNSPEC if target hook > says it is ok for debug regressed the following testcase, where creative > simplify-rtx.c changes result in (const (neg (unspec ... UNSPEC_GOTOFF))) > being emitted an

[PATCH] Fix dwarf2out ICE with UNSPEC_GOTOFF (PR debug/82837)

2017-11-06 Thread Jakub Jelinek
Hi! My recent changes to const_ok_for_output_1 to allow UNSPEC if target hook says it is ok for debug regressed the following testcase, where creative simplify-rtx.c changes result in (const (neg (unspec ... UNSPEC_GOTOFF))) being emitted and the backend not being able to assemble that (assembler

Re: [PATCH] Fix dwarf2out ICE with self-inlining (PR debug/80321)

2017-04-13 Thread Richard Biener
On Fri, Apr 7, 2017 at 11:42 PM, Jakub Jelinek wrote: > Hi! > > The following C and Ada testcases show ICE due to endless recursion in > dwarf2out.c. The problem is that when processing BLOCK_NONLOCALIZED_VARS, > we want to treat all the FUNCTION_DECLs in there as mere declarations, > but gen_sub

[PATCH] Fix dwarf2out ICE with self-inlining (PR debug/80321)

2017-04-07 Thread Jakub Jelinek
Hi! The following C and Ada testcases show ICE due to endless recursion in dwarf2out.c. The problem is that when processing BLOCK_NONLOCALIZED_VARS, we want to treat all the FUNCTION_DECLs in there as mere declarations, but gen_subprogram_die does: int declaration = (current_function_decl != de

Re: [PATCH] Fix dwarf2out ICE with C++17 inline static data members with redundant redeclaration (PR debug/80234)

2017-04-06 Thread Jeff Law
On 03/29/2017 01:42 PM, Jakub Jelinek wrote: Hi! When a C++17 inline static data member has a redundant out-of-class deprecated redeclaration, we can end up with 2 DW_TAG_variable in DW_TAG_compile_unit, one DW_AT_declaration and one with DW_AT_specification pointing to it (the latter emitted fo

[PATCH] Fix dwarf2out ICE with C++17 inline static data members with redundant redeclaration (PR debug/80234)

2017-03-29 Thread Jakub Jelinek
Hi! When a C++17 inline static data member has a redundant out-of-class deprecated redeclaration, we can end up with 2 DW_TAG_variable in DW_TAG_compile_unit, one DW_AT_declaration and one with DW_AT_specification pointing to it (the latter emitted for the redeclaration), before gen_member_die can

[PATCH] Fix dwarf2out ICE

2015-09-21 Thread Richard Biener
When testing with -g g++.dg/ext/attr-alias-3.C ICEs because we mess up the context of class-scope vars with aliases. The following fixes this. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied. Richard. 2015-09-21 Richard Biener * passes.c (rest_of_decl_compilation): Do

Re: [PATCH] Fix dwarf2out ICE (PR debug/65771)

2015-04-17 Thread Richard Biener
On Thu, Apr 16, 2015 at 11:11 PM, Jakub Jelinek wrote: > Hi! > > As mentioned in the PR, on the following testcase we ICE, because for > # DEBUG D#2 => b > # DEBUG D#1 => a[D#2].t > # DEBUG c => D#1 > during expansion we get the a[D#2].t added as MEM_EXPR of a MEM, and because > we can't mem

[PATCH] Fix dwarf2out ICE (PR debug/65771)

2015-04-16 Thread Jakub Jelinek
Hi! As mentioned in the PR, on the following testcase we ICE, because for # DEBUG D#2 => b # DEBUG D#1 => a[D#2].t # DEBUG c => D#1 during expansion we get the a[D#2].t added as MEM_EXPR of a MEM, and because we can't mem_loc_descriptor that MEM (I'll post separately a trunk only patch that

Re: [PATCH] Fix dwarf2out ICE (PR debug/63342)

2014-10-01 Thread Jason Merrill
On 10/01/2014 04:39 PM, Jakub Jelinek wrote: Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Ok except for the MEM_REF change for 4.9/4.8 (where the mem_loc_descriptor fix also went)? Yes. Jason

[PATCH] Fix dwarf2out ICE (PR debug/63342)

2014-10-01 Thread Jakub Jelinek
Hi! Since r214899 we ICE on the following testcase, because when mem_loc_descriptor gives up on a complex TLS related address that can't be (easily) delegitimized, we try to build location description from MEM_EXPR, but in this case it is a TARGET_MEM_REF which wasn't handled. I've implemented mor