From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59039 invoked by alias); 16 Mar 2016 17:02:38 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 59024 invoked by uid 89); 16 Mar 2016 17:02:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1736, Rather, xxx X-HELO: mail-qg0-f42.google.com Received: from mail-qg0-f42.google.com (HELO mail-qg0-f42.google.com) (209.85.192.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 16 Mar 2016 17:02:35 +0000 Received: by mail-qg0-f42.google.com with SMTP id u110so48378915qge.3 for ; Wed, 16 Mar 2016 10:02:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=M84XLbIKLCDJoWYUvXqUNnJUfqSbMIKhQfLgrGIXSyo=; b=Uk/yVg6hGdbND4s6jfj+FAazmpGdIY2rGOA1lCYj7VPMUtXc+bVrVgVmlonYOM9/or it39mc/zH8Z4a4SsqHwGGL5u90g1ugR1fvzATm2rii5jhNA67n/VEXt/9tHLPAPooauA EYxbv+JnmYrnBQTG6MmhffycV0Ux7hgyrcMpMaE5q8NfEWYpbDau+9e+Sd2vH2kOflYc lm3cMwTw4YGt8Nc+bPuQtTpNLKBzo3pILB3RMpKwTy8Sm0mUZ0sxU44gNuWnv8yRtBK0 kLkYuJ4HVH+FrwX8ZKeqHpKCTsLWpfo/UCyZhcmSJZrkYuvY8Wy5OaF6eHZYMCI7cyfZ z4xQ== X-Gm-Message-State: AD7BkJI7XPF7naK6nDte7mDGI3Mf25jK+pJ6XNmmLGBF3gQUw+sEJTIoky+9P9qAzutfyWOvnyI2vH09IR8abg== MIME-Version: 1.0 X-Received: by 10.140.31.135 with SMTP id f7mr2962455qgf.96.1458147753223; Wed, 16 Mar 2016 10:02:33 -0700 (PDT) Received: by 10.55.15.199 with HTTP; Wed, 16 Mar 2016 10:02:33 -0700 (PDT) In-Reply-To: <56E990BE.1020104@redhat.com> References: <20160302162538.66068C88E@oc7340732750.ibm.com> <56E82BC4.7070401@redhat.com> <56E8633B.8070303@redhat.com> <56E990BE.1020104@redhat.com> Date: Wed, 16 Mar 2016 17:02:00 -0000 Message-ID: Subject: Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class From: "H.J. Lu" To: Jason Merrill Cc: Ulrich Weigand , GCC Patches , Jakub Jelinek , Richard Biener , Markus Trippelsdorf Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00935.txt.bz2 On Wed, Mar 16, 2016 at 9:58 AM, Jason Merrill wrote: > On 03/16/2016 08:38 AM, H.J. Lu wrote: >> >> FAIL: g++.dg/abi/pr60336-1.C scan-assembler jmp[\t >> ]+[^$]*?_Z3xxx9true_type >> FAIL: g++.dg/abi/pr60336-5.C scan-assembler jmp[\t >> ]+[^$]*?_Z3xxx9true_type >> FAIL: g++.dg/abi/pr60336-6.C scan-assembler jmp[\t >> ]+[^$]*?_Z3xxx9true_type >> FAIL: g++.dg/abi/pr60336-7.C scan-assembler jmp[\t >> ]+[^$]*?_Z3xxx9true_type >> FAIL: g++.dg/abi/pr60336-9.C scan-assembler jmp[\t >> ]+[^$]*?_Z3xxx9true_type >> FAIL: g++.dg/abi/pr68355.C scan-assembler jmp[\t >> ]+[^$]*?_Z3xxx17integral_constantIbLb1EE > > > These pass for me on x86_64, but I do see calls with -m32. > >> They are expected since get_ref_base_and_extent needs to be >> changed to set bitsize to 0 for empty types so that when >> ref_maybe_used_by_call_p_1 calls get_ref_base_and_extent to >> get 0 as the maximum size on empty type. Otherwise, find_tail_calls >> won't perform tail call optimization for functions with empty type >> parameters. > > > That isn't why the optimization isn't happening in pr68355 with -m32; the > .optimized dump has > > xxx (D.2289); [tail call] > > Rather, the failure seems to happen in load_register_parameter, at > >> /* Check for overlap with already clobbered argument area, >> providing that this has non-zero size. */ >> if (is_sibcall >> && (size == 0 >> || mem_overlaps_already_clobbered_arg_p >> (XEXP (args[i].value, 0), >> size))) >> *sibcall_failure = 1; > > > The code seems to contradict the comment, and seems to have been broken by > r162402. Applying this additional patch fixes those tests. > I am running the full test now. -- H.J.