From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73930 invoked by alias); 9 Dec 2015 16:32:46 -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 73917 invoked by uid 89); 9 Dec 2015 16:32:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: DUB004-OMC4S3.hotmail.com Received: from dub004-omc4s3.hotmail.com (HELO DUB004-OMC4S3.hotmail.com) (157.55.2.78) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Wed, 09 Dec 2015 16:32:35 +0000 Received: from emea01-db3-obe.outbound.protection.outlook.com ([157.55.2.71]) by DUB004-OMC4S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 9 Dec 2015 08:32:32 -0800 Received: from VI1PR07MB0911.eurprd07.prod.outlook.com (10.161.109.11) by VI1PR07MB0912.eurprd07.prod.outlook.com (10.161.109.12) with Microsoft SMTP Server (TLS) id 15.1.337.19; Wed, 9 Dec 2015 16:32:31 +0000 Received: from VI1PR07MB0911.eurprd07.prod.outlook.com ([10.161.109.11]) by VI1PR07MB0911.eurprd07.prod.outlook.com ([10.161.109.11]) with mapi id 15.01.0337.015; Wed, 9 Dec 2015 16:32:31 +0000 From: Bernd Edlinger To: Bernd Schmidt , "gcc-patches@gcc.gnu.org" CC: Richard Biener , Jeff Law Subject: Re: [PATCH] Make basic asm implicitly clobber memory, pr24414 Date: Wed, 09 Dec 2015 16:32:00 -0000 Message-ID: References: <56680B27.5090405@redhat.com> <56684D4B.9020308@redhat.com> In-Reply-To: <56684D4B.9020308@redhat.com> authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=hotmail.de; x-ms-exchange-messagesentrepresentingtype: 1 x-microsoft-exchange-diagnostics: 1;VI1PR07MB0912;23:WgSrHOuZTmVjriL38GDWIJXpNlMkvNpk6a9ImlpaJUEkN2vpZw5bk/eisq3pnJOZ4Ta/VYKZJ4qCEgb8AYdLb2LPugLdqEoSAXVVk0NyihyJgP4P4EZsU1QBeDsnOuob7m3LX98BZXKvd+bsSEqmTsiCUaGjHpQgirCm6lVC844zxrlWsYnyhPFkac0kOibJ8J4o8gIdkiWxBTR8pzUFdQ==;5:9CA5ux0QVzx5MUskELvaKd3iPjw0NJFmn1QF7+Ct/0mZFCHE++a40cPrjA+9Oy0nM8e7VG0gVEyLZ4/Y9Y3Z4hnuv/B3/5gvpxPWkEw6lHYzb5JB4hzx9KNCN9Aayk7FulvMRACwjcOmf6XI3WVgqg==;24:c5Nmdd9Z1GBgSWv1ej7ilEBSJjTXJ4TAAMuGDKOP5Oc4TfiRlSepsXpPa+sZshph2YxUMm/3yRDhBY+vN9Zrr1rfgNow6HbfE6SzQUfsNqA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB0912; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(432015012)(81415001)(82015046);SRVR:VI1PR07MB0912;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB0912; x-forefront-prvs: 0785459C39 x-forefront-antispam-report: SFV:NSPM;SFS:(7070004)(98900002);DIR:OUT;SFP:1901;SCL:1;SRVR:VI1PR07MB0912;H:VI1PR07MB0911.eurprd07.prod.outlook.com;FPR:;SPF:None;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sct-15-1-318-9-msonline-outlook-efc2f.templateTenant X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2015 16:32:30.9154 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB0912 X-SW-Source: 2015-12/txt/msg01025.txt.bz2 Hi, On 09.12.2015 16:48 Bernd Schmidt wrote: > On 12/09/2015 04:09 PM, Bernd Edlinger wrote: > >> So would you agree on the general direction of the patch, >> if I drop the hunk in sched-deps.c ? > > I'm not sure there was any consensus in that other thread, but I think=20 > assuming that basic asms clobber memory and CC, can be justified. That=20 > certainly seems like a safer default. Ideally though I think it would=20 > be best if we could deprecate basic asms in functions, or at least=20 > warn about them in -Wall. > > Well no, we did not get to a consensus on the warning issue. My personal gut feeling on that warning is a bit mixed... If we have a -Wall-enabled warning on asm("..."), people who know next=20 to nothing about assembler will be encouraged to "fix" this warning in a part of=20 the code which they probably do not understand at all. This frightens me a bit. Because I know they will soon find out, that adding a few colons fixes=20 the warning, but asm("...":::) is not any better IMHO. For me, it is just very very unlikely that any piece of assembler really=20 clobbers nothing and has no inputs and no outputs at the same time, even it it looks so=20 at first sight... It is much more likely that someone forgot to fill in the clobber section. So for me it would also be good to warn on asm("...":::) and require=20 that, if they want to fix this warning, they must at least write something in the clobber section, like asm ("...":::"nothing"); that would be a new clobber name=20 which can only stand alone and, which can get stripped after the warning processing=20 took place in the FE. So I think a warning should warn on something that is so unusual that it=20 is likely a bug. Bernd.