From patchwork Wed Aug 29 17:36:15 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nathan Sidwell X-Patchwork-Id: 963589 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-484727-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=acm.org Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="grFLbYkr"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 420t8Y4KsXz9ryn for ; Thu, 30 Aug 2018 03:36:28 +1000 (AEST) Received: (qmail 46643 invoked by alias); 29 Aug 2018 17:36:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 46631 invoked by uid 89); 29 Aug 2018 17:36:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.1 required=5.0 tests=BAYES_00, FREEMAIL_FROM, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=91, tre, bob, PLUS_EXPR X-HELO: mail-yw1-f52.google.com Received: from mail-yw1-f52.google.com (HELO mail-yw1-f52.google.com) (209.85.161.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Aug 2018 17:36:19 +0000 Received: by mail-yw1-f52.google.com with SMTP id x67-v6so2323796ywg.0 for ; Wed, 29 Aug 2018 10:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:to:cc:from:subject:message-id:date:user-agent:mime-version :content-language; bh=ZJWw1qqd+NtWJ3kNSr7zqK7Rz+EIEkHpLkoWuZDOBCI=; b=grFLbYkr7J/KoztVekbmbvSagMl1ZElEvC+rCkvkVaXBjXJC2gcN86XPYjqt2MjQ8X KzTVwq70LOvr4WC/ya369gYjXFS7DKng4VKDetoSX9JHYwApAw/3lca1tmLGLraPC7UC QQjazpfap/suBjHYIpRu+lr9IIIOVDbkhMKPaRrPkTsqpHYnenhoLZfNntc4xS58t15B HrEz5eigPeVp7v+uofZd0Uh9xqSASwMlSYEDEitfZG2vHnaBd23xmKfw5c9rI7NoCPoC OPeXg+gPAkaIc+j/+46gj6ekuTLTSLq+TOHB715ho5KDcMmudCgLhsEGXwdPG8lcuHDu QgtA== Received: from ?IPv6:2620:10d:c0a3:20fb:7500:e7fb:4a6f:2254? ([2620:10d:c091:200::3:c6f]) by smtp.googlemail.com with ESMTPSA id z7-v6sm4910617ywz.21.2018.08.29.10.36.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Aug 2018 10:36:17 -0700 (PDT) Sender: Nathan Sidwell To: GCC Patches Cc: Jason Merrill , Richard Biener , David Edelsohn , 10walls@gmail.com, Alexandre Oliva , lh_mouse@126.com From: Nathan Sidwell Subject: [PR c++/87137] GCC-8 Fix Message-ID: <1ae01cf1-3c10-84a8-418f-efa38ad78032@acm.org> Date: Wed, 29 Aug 2018 13:36:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 This defect concerns bitfield layout in the Microsoft ABI. This is a fix for gcc-8. As well as MINGW targets, MS-ABI can be enabled on PowerPC & SuperH by suitable use of attributes or options. When I folded TYPE_METHODS into TYPE_FIELDS, the 'am I the last field' check of place_field could give a false positive in more cases. Specifically if two bitfields were separated by a member function declaration, they'd now be placed in separate allocation units. The place_field code was working under the assumption that the only things on the TYPE_FIELDS list could be FIELD_DECLs possibly followed by TYPE_DECLs. That stopped being true some time ago, and as such we already had a layout bug. But, it would be bad to make that particular ABI fix in a point release, so this patch just reverts the regression I caused. Sadly, because it requires understanding TEMPLATE_DECL, we can't simply update place_field. Instead I temporarily stitch out undesired DECLs around the call to place_field. This seems the least intrusive, and happens only when ms_bitfield_layout_p is in effect. I have manually checked the new testcase behaves the same in gcc-7 and patched gcc-8 for an x86_64-mingw32 target. Liu Hao has verified that the microsoft compiler gives the same results. I also attach a change to wwwdocs describing this change. Thoughts? nathan Index: htdocs/gcc-8/changes.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-8/changes.html,v retrieving revision 1.93 diff -r1.93 changes.html 1350a1351,1374 > >

GCC 8.3

> > GCC 8.3 is not yet released. > >

Structure Layout for Windows, PowerPC & SuperH targets

A > C++ Microsoft ABI bitfield layout > regression, PR87137 > introduced in GCC 8.1, has been fixed. A declaration of a member > function or member function templare could cause the current > bitfield allocation unit to be completed, incorrectly placing a > following bitfield into a new allocation unit. Microsoft ABI is > selected for: >
    >
  • Mingw targets >
  • PowerPC targets when __attribute__((ms_struct)) > is used >
  • SuperH targets when the -mhitachi option is > specified, or the __attribute__((renesas)) > attribute is used >
> The layout bug could also be triggered by other intermediate > declarations. This pre-existing issue will be fixed in GCC 9.1. >