[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" <gcc-bugzilla@gcc.gnu.org>]

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_traits<char>;
>> 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_streambuf<wchar_t>::seekpos (this_2(D), D.23077,
>> _3(D)); [tail call]
>>    return <retval>;
>>
>> }
>>
>> where std::basic_streambuf<_CharT, _Traits>::pos_type is:
>>   <result_decl 0x7ffff4eec708 D.39821
>>      type <record_type 0x7ffff59c2150 pos_type sizes-gimplified asm_written used
>> needs-constructing type_1 type_5 TI
>>          size <integer_cst 0x7ffff6c2fe40 constant 128>
>>          unit size <integer_cst 0x7ffff6c2fe58 constant 16>
>>          align 64 symtab -164402368 alias set -1 canonical type 0x7ffff614adc8
>>          fields <field_decl 0x7ffff51cd850 _M_off type <integer_type
>> 0x7ffff678c738 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 0x7ffff6c2fdf8 constant 64>
>>              unit size <integer_cst 0x7ffff6c2fe10 constant 8>
>>              align 64 offset_align 128
>>              offset <integer_cst 0x7ffff6c2fe28 constant 0>
>>              bit offset <integer_cst 0x7ffff6c2fe70 constant 0> context
>> <record_type 0x7ffff614adc8 fpos> chain <field_decl 0x7ffff51cd8e8 _M_state>>
>> context <namespace_decl 0x7ffff6c4c098 std>
>>          full-name "std::basic_streambuf<char>::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 0x7ffff5224e70> chain <type_decl
>> 0x7ffff6146da8 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 0x7ffff6c2fe40 128> unit size <integer_cst
>> 0x7ffff6c2fe58 16>
>>      align 64 context <function_decl 0x7ffff5797948 seekoff>>
>>
>> Is there a bug in expand_thunk or do I miss something?
>> Thanks,
>> Martin
>>
>>
>
>From gcc-bugs-return-464910-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 10:38:01 2014
Return-Path: <gcc-bugs-return-464910-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9660 invoked by alias); 24 Oct 2014 10:38:01 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9331 invoked by uid 55); 24 Oct 2014 10:37:57 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/63587] [5 Regression] ICE : tree check: expected var_decl, have result_decl in add_local_variables, at tree-inline.c:4112
Date: Fri, 24 Oct 2014 10:39:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63587-4-qMLN7SFsSg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63587-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63587-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01931.txt.bz2
Content-length: 2323

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

--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 24 Oct 2014, mliska at suse dot cz wrote:

> 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?

Yes.

Richard.
>From gcc-bugs-return-464911-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 10:39:00 2014
Return-Path: <gcc-bugs-return-464911-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12353 invoked by alias); 24 Oct 2014 10:39:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 12323 invoked by uid 48); 24 Oct 2014 10:38:56 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60304] Including <atomic> disables -Wconversion-null
Date: Fri, 24 Oct 2014 10:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60304-4-PP4IpGDrgg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60304-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60304-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01932.txt.bz2
Content-length: 825

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

--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Paolo Carlini from comment #5)
> Well, of course the user can always explicitly include, eg, <cstdbool>, thus
> it seems that the real underlying issue is that the system-headers machinery
> should not be fooled by things like this in a system header... or should it?
> The define is rather interesting...
> 
> #define false false
> 
> I'm adding in CC Dodji too...

In the case of NULL we do:

      source_location loc =
    expansion_point_location_if_in_system_header (input_location);

however, we do not do it in the case of 'false' (because we do not think it
should be a macro, but it actually is). Perhaps we should do it, is there a
downside to it?
>From gcc-bugs-return-464912-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 10:45:08 2014
Return-Path: <gcc-bugs-return-464912-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20126 invoked by alias); 24 Oct 2014 10:45:08 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20087 invoked by uid 48); 24 Oct 2014 10:45:04 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60304] Including <atomic> disables -Wconversion-null
Date: Fri, 24 Oct 2014 10:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60304-4-CWM3jEPBjN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60304-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60304-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01933.txt.bz2
Content-length: 1098

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

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #9)
> (In reply to Paolo Carlini from comment #5)
> > Well, of course the user can always explicitly include, eg, <cstdbool>, thus
> > it seems that the real underlying issue is that the system-headers machinery
> > should not be fooled by things like this in a system header... or should it?
> > The define is rather interesting...
> > 
> > #define false false
> > 
> > I'm adding in CC Dodji too...
> 
> In the case of NULL we do:
> 
>       source_location loc =
> 	expansion_point_location_if_in_system_header (input_location);
> 
> however, we do not do it in the case of 'false' (because we do not think it
> should be a macro, but it actually is). Perhaps we should do it, is there a
> downside to it?

BTW, this is the guideline I was asking for here:

https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01783.html

In this case, 'false' is one of those special macros.
>From gcc-bugs-return-464913-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Oct 24 10:53:46 2014
Return-Path: <gcc-bugs-return-464913-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31503 invoked by alias); 24 Oct 2014 10:53:46 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 31434 invoked by uid 55); 24 Oct 2014 10:53:42 -0000
From: "fyang at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63173] performance problem with simd intrinsics vld2_dup_* on aarch64-none-elf
Date: Fri, 24 Oct 2014 11:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fyang at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: fei.yang0953 at gmail dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63173-4-uGEBZPKRIz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63173-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63173-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-10/txt/msg01934.txt.bz2
Content-length: 2352

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc173

--- Comment #8 from fyang at gcc dot gnu.org ---
Author: fyang
Date: Fri Oct 24 10:53:08 2014
New Revision: 216630

URL: https://gcc.gnu.org/viewcvs?rev!6630&root=gcc&view=rev
Log:
        PR target/63173
        * config/aarch64/arm_neon.h (__LD2R_FUNC): Remove macro.
        (__LD3R_FUNC): Ditto.
        (__LD4R_FUNC): Ditto.
        (vld2_dup_s8, vld2_dup_s16, vld2_dup_s32, vld2_dup_f32, vld2_dup_f64,
         vld2_dup_u8, vld2_dup_u16, vld2_dup_u32, vld2_dup_p8, vld2_dup_p16
         vld2_dup_s64, vld2_dup_u64, vld2q_dup_s8, vld2q_dup_p8,
         vld2q_dup_s16, vld2q_dup_p16, vld2q_dup_s32, vld2q_dup_s64,
         vld2q_dup_u8, vld2q_dup_u16, vld2q_dup_u32, vld2q_dup_u64
         vld2q_dup_f32, vld2q_dup_f64): Rewrite using builtin functions.
        (vld3_dup_s64, vld3_dup_u64, vld3_dup_f64, vld3_dup_s8
         vld3_dup_p8, vld3_dup_s16, vld3_dup_p16, vld3_dup_s32
         vld3_dup_u8, vld3_dup_u16, vld3_dup_u32, vld3_dup_f32
         vld3q_dup_s8, vld3q_dup_p8, vld3q_dup_s16, vld3q_dup_p16
         vld3q_dup_s32, vld3q_dup_s64, vld3q_dup_u8, vld3q_dup_u16
         vld3q_dup_u32, vld3q_dup_u64, vld3q_dup_f32, vld3q_dup_f64): Likewise.
        (vld4_dup_s64, vld4_dup_u64, vld4_dup_f64, vld4_dup_s8
         vld4_dup_p8, vld4_dup_s16, vld4_dup_p16, vld4_dup_s32
         vld4_dup_u8, vld4_dup_u16, vld4_dup_u32, vld4_dup_f32
         vld4q_dup_s8, vld4q_dup_p8, vld4q_dup_s16, vld4q_dup_p16
         vld4q_dup_s32, vld4q_dup_s64, vld4q_dup_u8, vld4q_dup_u16
         vld4q_dup_u32, vld4q_dup_u64, vld4q_dup_f32, vld4q_dup_f64): Likewise.
        * config/aarch64/aarch64.md (define_c_enum "unspec"): Add
        UNSPEC_LD2_DUP, UNSPEC_LD3_DUP, UNSPEC_LD4_DUP.
        * config/aarch64/aarch64-simd-builtins.def (ld2r, ld3r, ld4r): New
        builtins.
        * config/aarch64/aarch64-simd.md (aarch64_simd_ld2r<mode>): New
pattern.
        (aarch64_simd_ld3r<mode>): Likewise.
        (aarch64_simd_ld4r<mode>): Likewise.
        (aarch64_ld2r<mode>): New expand.
        (aarch64_ld3r<mode>): Likewise.
        (aarch64_ld4r<mode>): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/aarch64/aarch64-simd-builtins.def
    trunk/gcc/config/aarch64/aarch64-simd.md
    trunk/gcc/config/aarch64/aarch64.md
    trunk/gcc/config/aarch64/arm_neon.h