From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-408241-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 116654 invoked by alias); 24 Sep 2015 14:07:24 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 116637 invoked by uid 89); 24 Sep 2015 14:07:23 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-io0-f182.google.com
Received: from mail-io0-f182.google.com (HELO mail-io0-f182.google.com) (209.85.223.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 24 Sep 2015 14:07:22 +0000
Received: by ioii196 with SMTP id i196so77811224ioi.3        for <gcc-patches@gcc.gnu.org>; Thu, 24 Sep 2015 07:07:20 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.160.196 with SMTP id j187mr681060ioe.91.1443103640016; Thu, 24 Sep 2015 07:07:20 -0700 (PDT)
Received: by 10.36.73.14 with HTTP; Thu, 24 Sep 2015 07:07:19 -0700 (PDT)
In-Reply-To: <CAMbmDYaDWjZoked4pp5KhGiypWGVWWmC3xNG7_=pmUdS79fkww@mail.gmail.com>
References: <20150901143909.GB55610@msticlxl57.ims.intel.com>	<CAFiYyc3kvXa2UN_j5Sdheyg7iLLb-zcaisSe2g8ZAh6eMiR9hw@mail.gmail.com>	<CAMbmDYYQBK=mXnizUj_-xa_DgsdGspKYzUo=na3yDcPDXtRqgw@mail.gmail.com>	<CAFiYyc2kWF+CuoXupEmc=9m=9HPq4NaL8UsCDV7EHD-J+=iZpA@mail.gmail.com>	<CAMbmDYbQMVk7c_ri1Fag77m-gTFfmL7RTKJ2zgqD-j8=1yb3rA@mail.gmail.com>	<CAFiYyc1=Wu4U=9RR_xb4dKPp9HXxJ3z3=AebJJFjW-s6hQXsDQ@mail.gmail.com>	<CAMbmDYaDWjZoked4pp5KhGiypWGVWWmC3xNG7_=pmUdS79fkww@mail.gmail.com>
Date: Thu, 24 Sep 2015 15:13:00 -0000
Message-ID: <CAMbmDYbZoaL6DaXEwydxh92PfX2fktw9m-SsFFQsfhU9j-jQuA@mail.gmail.com>
Subject: Re: [PATCH, PR67405, committed] Avoid NULL pointer dereference
From: Ilya Enkovich <enkovich.gnu@gmail.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes
X-SW-Source: 2015-09/txt/msg01866.txt.bz2

2015-09-15 14:01 GMT+03:00 Ilya Enkovich <enkovich.gnu@gmail.com>:
> 2015-09-15 13:32 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
>> On Tue, Sep 15, 2015 at 11:28 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>>
>> I see.  I wonder why we even call chkp_find_bound_slots if seen_errors().
>
> Even with errors we still gimplify function. Function parameters
> gimplification checks where parameters are passed to possibly copy
> some of them. It triggers ix86_function_arg_advance which uses
> chkp_find_bound_slots to skip required amount of bounds registers.
>
>> I suppose only recursing for COMPLETE_TYPE_P () would work?
>
> Yep, it should work. I'll rework my fix.

It turned out to be wrong. For this test

struct S
{
  S f;
};

void fn1 (S p1) {}

Structure S is considered as complete (has size 8 for some reason) at
fn1 gimplification. Thus even with complete type check I still hit
this field with error_node instead of a type and NULL at
DECL_FIELD_BIT_OFFSET. Should my current fix be OK then?

Thanks,
Ilya