From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45165 invoked by alias); 19 Feb 2016 11:53:10 -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 45153 invoked by uid 89); 19 Feb 2016 11:53:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=anxious X-HELO: DUB004-OMC4S5.hotmail.com Received: from dub004-omc4s5.hotmail.com (HELO DUB004-OMC4S5.hotmail.com) (157.55.2.80) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Fri, 19 Feb 2016 11:53:08 +0000 Received: from emea01-am1-obe.outbound.protection.outlook.com ([157.55.2.72]) by DUB004-OMC4S5.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 19 Feb 2016 03:53:05 -0800 Received: from HE1PR07MB0905.eurprd07.prod.outlook.com (10.162.26.12) by HE1PR07MB0907.eurprd07.prod.outlook.com (10.162.26.14) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 19 Feb 2016 11:53:04 +0000 Received: from HE1PR07MB0905.eurprd07.prod.outlook.com ([10.162.26.12]) by HE1PR07MB0905.eurprd07.prod.outlook.com ([10.162.26.12]) with mapi id 15.01.0409.017; Fri, 19 Feb 2016 11:53:03 +0000 From: Bernd Edlinger To: Jakub Jelinek CC: "gcc-patches@gcc.gnu.org" , Jason Merrill , Jonathan Wakely Subject: Re: [C++ PATCH] Fix option handling when -std=gnu++14 is not used (PR 69865) Date: Fri, 19 Feb 2016 11:53:00 -0000 Message-ID: References: <20160219105612.GA3017@tucnak.redhat.com> ,<20160219113126.GB3017@tucnak.redhat.com> In-Reply-To: <20160219113126.GB3017@tucnak.redhat.com> authentication-results: gcc.gnu.org; dkim=none (message not signed) header.d=none;gcc.gnu.org; dmarc=none action=none header.from=hotmail.de; x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [wWnuDefYcNvHVbumKXOLAUy2m2Ea8PXa] x-microsoft-exchange-diagnostics: 1;HE1PR07MB0907;23:MrKd07gQ9sW7VBjhzGHSXNwwUb30CJr1GVJkPJva2zxu4/9Z5xbqtz1dmNqThA81dfVMk2zjnMhVAaZu2rYFdhDOGt19w67c0rMZGoHF42xwC2IIwCICKhqRQeny67y2O1xiJY7V8r/RaPWtuYwnFv3rw9JVf27BQv5r3lGg2da2/5eaRHcCIOAoxRNaHGUozIGTr1YoYKAWPNoNeFJ8nw==;5:vXgmki0TmUq+o8IsHQhZNi34x5Q3zNDwVTNKc05ks0O9stIoSBiQ/snfuWtkARjeaS7ZEdlosDJZ2JtsvksSmY05oNI6hpJL2PCZkLCNBMg4D9HolJSJzpKOo0nwSziSKsdCvmTv8IS1U4xaJ7VyUQ==;24:0RfgFuWsACxuIHgWNvRhsMlJ26DhO0bUWzrUaJzJByqlzmHrLKj5nFzQt0wwKAJ80CGTedBDRtAa+gWUnYRaBu/g5LP79yX8+PZJWqC41k8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB0907; x-ms-office365-filtering-correlation-id: 088eb4f5-286a-48d7-bb4d-08d33923395e x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(432015012)(82015046);SRVR:HE1PR07MB0907;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB0907; x-forefront-prvs: 08572BD77F x-forefront-antispam-report: SFV:NSPM;SFS:(7070004)(98900003);DIR:OUT;SFP:1901;SCL:1;SRVR:HE1PR07MB0907;H:HE1PR07MB0905.eurprd07.prod.outlook.com;FPR:;SPF:None;MLV:ovrnspm;LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sct-15-1-409-10-msonline-outlook-d6129.templateTenant X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2016 11:53:03.7270 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0907 X-SW-Source: 2016-02/txt/msg01317.txt.bz2 On 19.02.2016 12:31, Jakub Jelinek wrote: > On Fri, Feb 19, 2016 at 11:08:48AM +0000, Bernd Edlinger wrote: > > On 19.02.2016 11:56, Jakub Jelinek wrote: > > > > > > On Fri, Feb 19, 2016 at 10:50:34AM +0000, Bernd Edlinger wrote: > > > > While I think that we should probably not define __GNUC_GNU_INLINE_= _ at all for C++, > > > > because it is meaningless, I am warned that this could break (alrea= dy broken) header files. > > > > > > It is not meaningless. The various headers need to know if it is saf= e to > > > use the gnu_inline attribute in C++. > > > > > > In any case, the desirable state is that e.g. the -E -dD output shoul= d be > > > identical if you explicitly request the default -std=3D version vs. i= f it is > > > set implicitly. We should verify it is the case even for C. > > > > > > Jakub > > > > I absolutely agree with you. > > The correct solution is probably doing this: > > > > --- gcc/cp/cfns.h.jj 2016-01-04 15:30:50.000000000 +0100 > > +++ gcc/cp/cfns.h 2016-02-19 12:00:15.730375049 +0100 > > @@ -124,9 +124,6 @@ > > > > #ifdef __GNUC__ > > __inline > > -#ifdef __GNUC_STDC_INLINE__ > > -__attribute__ ((__gnu_inline__)) > > -#endif > > #endif > > const char * > > libc_name_p (register const char *str, register unsigned int len) >=20 > This is of course wrong. cfns.h is a generated header, so you shouldn't > patch it. > If it is regenerated with a newer gperf (I have 3.0.4 installed), you get= there: > @@ -124,7 +124,7 @@ hash (register const char *str, register >=20 > #ifdef __GNUC__ > __inline > -#ifdef __GNUC_STDC_INLINE__ > +#if defined __GNUC_STDC_INLINE__ || defined __GNUC_GNU_INLINE__ > __attribute__ ((__gnu_inline__)) > #endif > #endif >=20 > Jakub Damnit!! I dont know how this file is ever supposed to compile on a C99 compiler. but with this change it does not even compile with -std=3Dc90 any more: cat test.c #include "cfns.h" gcc -std=3Dc90 test.c In file included from test.c:1:0: cfns.gperf:101:1: error: 'gnu_inline' attribute present on 'libc_name_p' cfns.gperf:26:14: error: but not here gcc -std=3Dc99 test.c In file included from test.c:1:0: cfns.gperf:101:1: error: 'gnu_inline' attribute present on 'libc_name_p' cfns.gperf:26:14: error: but not here cfns.gperf: In function 'libc_name_p': cfns.gperf:328:34: warning: implicit declaration of function 'strcmp' [-Wim= plicit-function-declaration] So this leaves only one solution, to define neither __GNUC_STDC_INLINE__ nor __GNUC_GNU_INLINE__ for C++, at least the inline and gnu_inline is completely different on C and C++. But I am anxious this will break more things than gperf, and I would like to fix this in a safe way. Bernd.