From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-486342-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 97831 invoked by alias); 25 Sep 2018 14:42:32 -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 97617 invoked by uid 89); 25 Sep 2018 14:42:31 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=Hx-languages-length:795
X-HELO: mail-ot1-f65.google.com
Received: from mail-ot1-f65.google.com (HELO mail-ot1-f65.google.com) (209.85.210.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 25 Sep 2018 14:42:30 +0000
Received: by mail-ot1-f65.google.com with SMTP id 36-v6so24645194oth.11        for <gcc-patches@gcc.gnu.org>; Tue, 25 Sep 2018 07:42:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac9:1507:0:0:0:0:0 with HTTP; Tue, 25 Sep 2018 07:42:08 -0700 (PDT)
In-Reply-To: <20180925071754.GX8250@tucnak>
References: <20180925071754.GX8250@tucnak>
From: Jason Merrill <jason@redhat.com>
Date: Tue, 25 Sep 2018 14:57:00 -0000
Message-ID: <CADzB+2nc+62ioqFcPNJY7SKxsfQBMuXC=Xi-45V_P6zoWDBHbQ@mail.gmail.com>
Subject: Re: [C++ PATCH] Fix constexpr OBJ_TYPE_REF handling on array elts (PR c++/87398)
To: Jakub Jelinek <jakub@redhat.com>
Cc: Marek Polacek <polacek@redhat.com>, gcc-patches List <gcc-patches@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
X-IsSubscribed: yes
X-SW-Source: 2018-09/txt/msg01445.txt.bz2

On Tue, Sep 25, 2018 at 3:17 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> ARRAY_REF is a handled component, so when a virtual call is on an array
> element (or some component thereof), the loop to look through handled
> components will look through the ARRAY_REFs too and then TREE_TYPE (obj)
> might be an ARRAY_TYPE.  The code wants to look at the class type instead
> though.

Yeah, I think looping through handled components is wrong here; given
something like

struct A
{
  virtual void f();
};

struct B
{
  A a;
} b;

int main()
{
  b.a.f();
}

Looking through all handled components would give us "b", which has no
virtual functions.

I think we need to be more specific about what we're expecting here.

Jason