From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#27346: module tests fail to compile with gcc 4.8.5 Date: Tue, 13 Jun 2017 08:03:25 +0000 Message-ID: References: <99r2ypw1ip.fsf@fencepost.gnu.org> <83mv9d3vxw.fsf@gnu.org> <1fvao16jco.fsf@fencepost.gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113e40e05a98830551d2df4c" X-Trace: blaine.gmane.org 1497341056 522 195.159.176.226 (13 Jun 2017 08:04:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 13 Jun 2017 08:04:16 +0000 (UTC) Cc: 27346@debbugs.gnu.org To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 13 10:04:07 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dKgo3-00086y-J0 for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Jun 2017 10:04:07 +0200 Original-Received: from localhost ([::1]:41603 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dKgo8-0003Ds-Vs for geb-bug-gnu-emacs@m.gmane.org; Tue, 13 Jun 2017 04:04:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dKgo1-0003Da-90 for bug-gnu-emacs@gnu.org; Tue, 13 Jun 2017 04:04:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dKgny-000260-37 for bug-gnu-emacs@gnu.org; Tue, 13 Jun 2017 04:04:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41643) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dKgny-00025v-0P for bug-gnu-emacs@gnu.org; Tue, 13 Jun 2017 04:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dKgnx-0004un-P0 for bug-gnu-emacs@gnu.org; Tue, 13 Jun 2017 04:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Jun 2017 08:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27346 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27346-submit@debbugs.gnu.org id=B27346.149734102318867 (code B ref 27346); Tue, 13 Jun 2017 08:04:01 +0000 Original-Received: (at 27346) by debbugs.gnu.org; 13 Jun 2017 08:03:43 +0000 Original-Received: from localhost ([127.0.0.1]:44320 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dKgne-0004uF-Lm for submit@debbugs.gnu.org; Tue, 13 Jun 2017 04:03:42 -0400 Original-Received: from mail-ot0-f173.google.com ([74.125.82.173]:34766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dKgnd-0004u2-6d for 27346@debbugs.gnu.org; Tue, 13 Jun 2017 04:03:41 -0400 Original-Received: by mail-ot0-f173.google.com with SMTP id t31so82387142ota.1 for <27346@debbugs.gnu.org>; Tue, 13 Jun 2017 01:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6vr6A9CUW52a4pYBZjwnZIub7wRal0JyDq+39B42pqg=; b=ItOPl6cJn7SajRVTqOZWTQvuMawQdbDEhZxtiIPuwCDonJ1KFeAglZm2pA3dEuIhGY NDqyTfiylTJhAWkLi3eyBzyEN3gLhjmfpSuhy/tveGoV3yZhybkuePX3BGvZGlC648Tj l+amLn/XQlGXnjLOugLsiX66T8iPdh6lRnRDflQpJskxps7hBaMStClQOo9KHcy7CzkW Rcf3opCmNnsJpF17nnoGGcjNqJtQz8sS5Dxkb2wyZULeRILsE2KCTADcWdfif0fAO2YM +1bwu64jnrAHWkiPNupRnrkM2ux90qF1LdBgAuGAJlvK8Xce08MdaG+ah032u99RhCc0 8O7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6vr6A9CUW52a4pYBZjwnZIub7wRal0JyDq+39B42pqg=; b=WIjHFBiODLNOp60fa9ixyBKD39xJtRqlSn+5bzq9qRhfGazJTVURbioNTQ25lwQ5cI v85CJeVJLHrdB9Thz3R4x61cgOIG0i7UWzRWPmXYrhlwIaRYS7DJL8yHLkdMM7AFo6k8 eJZUWVvLeMH3UYfN0taq8JZj4+4mi/cOS04A+39KZ0Wt6HMLZjtpnJiOhXAuCO/kwIar P54pyRkC83ZvoXAMTkyQx28KZCFbAZvwpmrakaiEVnZ4ExyPPo1dKjhWi69TdYplkGtu GvClnwPffWtX6NwlPizjmK/5viBmtb7iyop4wpZmbw48dRj1gca8IsPQ5BAujlXnd30J gUcg== X-Gm-Message-State: AKS2vOxrQFkC0jWkv9FQ3QRDmefr8svI6nwaDqc+7a2ukE2CpAAnK98N wRedlzKpzpShOyAFB9oz13QWCZBCKaFa X-Received: by 10.157.37.244 with SMTP id q107mr1418193ota.44.1497341015789; Tue, 13 Jun 2017 01:03:35 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:133550 Archived-At: --001a113e40e05a98830551d2df4c Content-Type: text/plain; charset="UTF-8" Glenn Morris schrieb am Mo., 12. Juni 2017 um 23:46 Uhr: > Philipp Stephani wrote: > > >> +#ifdef __has_attribute > >> +#if __has_attribute(__nonnull__) > >> # define EMACS_ATTRIBUTE_NONNULL(...) > >> __attribute__((__nonnull__(__VA_ARGS__))) > >> -#else > >> +#endif > >> +#endif > >> +#ifndef EMACS_ATTRIBUTE_NONNULL > >> # define EMACS_ATTRIBUTE_NONNULL(...) > >> #endif > > Applied as 69899d4. > Thanks! > > > Probably yes, thanks. (I don't know why the && expression doesn't work.) > > I could not find a good reference, but see eg > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36453#c3 > > I've looked it up in the (C++) standard, and the explanation makes sense. What happens is that the preprocessor first replaces the 'define' forms and expands macros, then replaces all leftover identifiers (including C keywords) with 0. So #if defined __has_attribute && __has_attribute ((__nonnull__)) first gets translated to #if 0 && 0 ((0)) which is then evaluated, but it's a syntax error, which fails even if the LHS of && is false. --001a113e40e05a98830551d2df4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Glenn = Morris <rgm@gnu.org> schrieb am Mo= ., 12. Juni 2017 um 23:46=C2=A0Uhr:
Philipp Stephani wrote:

>> +#ifdef __has_attribute
>> +#if __has_attribute(__nonnull__)
>>=C2=A0 # define EMACS_ATTRIBUTE_NONNULL(...)
>>=C2=A0 __attribute__((__nonnull__(__VA_ARGS__)))
>> -#else
>> +#endif
>> +#endif
>> +#ifndef EMACS_ATTRIBUTE_NONNULL
>>=C2=A0 # define EMACS_ATTRIBUTE_NONNULL(...)
>>=C2=A0 #endif

Applied as 69899d4.

Thanks!
= =C2=A0

> Probably yes, thanks. (I don't know why the && expression = doesn't work.)

I could not find a good reference, but see eg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id= =3D36453#c3


I've looked it up in the (C++) sta= ndard, and the explanation makes sense. What happens is that the preprocess= or first replaces the 'define' forms and expands macros, then repla= ces all leftover identifiers (including C keywords) with 0. So
#if defined __has_attribute && __has_attribute ((__non= null__))

first gets translated to

#if 0 && 0 ((0))

which is then ev= aluated, but it's a syntax error, which fails even if the LHS of &&= amp; is false.=C2=A0
--001a113e40e05a98830551d2df4c--