From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57206 invoked by alias); 2 Nov 2017 14:42:43 -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 57196 invoked by uid 89); 2 Nov 2017 14:42:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy= X-HELO: mail-io0-f175.google.com Received: from mail-io0-f175.google.com (HELO mail-io0-f175.google.com) (209.85.223.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 02 Nov 2017 14:42:42 +0000 Received: by mail-io0-f175.google.com with SMTP id f20so14477722ioj.9 for ; Thu, 02 Nov 2017 07:42:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zQIKeMmW9C5DrgCNGnwnGIqN5dakiKJnIX0kgy9znH0=; b=s71g1OH4j0lrfkTxWzMbLciYcMP9JPEhb4ME6uwX51Iv3Rbnx7bAbQC9L46n4u/pgA soV0BJgqSQ3xBzhz1/nW+p9qQdfgDplJrU4x9fxqO4pe5fX1/GPhPcb0olnptey+vJ63 9lepKXrw/S87Hii2QiyeqTXVwlBVIl1/TpCGvETPp0N8LIQu4dLjyw1jdNGEylI7wKTX YYuiFrVZxYqVcd9I6M34y6gVPd1kxf9cLhyX6YwAuKlQJcSqMokopTtJJAQ31MbWVgQh Hqc+LliqtvHnNABlNT1KrC2vp6Xjc+v7SsI4oBkVxnFUsgxBYACdZliF6UhdNnXYA3MZ vvNg== X-Gm-Message-State: AJaThX7woiJadBiXMwJrYLVyBrJkJjT3FtzCHeoeF8g3TC6IFMgf5t6m 0eTLc5pkrkAr2LHTL5AtiQRNyVC76+8JsJEn2NawWA== X-Google-Smtp-Source: ABhQp+Q5Oea3b519p/5AtmqF0wsJjqu+iGY48z5abAYjHQvjPGTVOJU3rZoreobWRGmvrydWhjXl8kAoiUhkB+fR3s0= X-Received: by 10.107.159.5 with SMTP id i5mr4662459ioe.300.1509633760100; Thu, 02 Nov 2017 07:42:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.170.26 with HTTP; Thu, 2 Nov 2017 07:42:19 -0700 (PDT) In-Reply-To: References: <6bd671aa-97cf-1dcc-ca90-5948ab533113@oracle.com> <58ca43f6-e0a6-0419-8e46-cbb6b78f845c@acm.org> <8d9f3e13-9b65-da73-499c-05e569eef046@oracle.com> <4e6e0a54-cf50-8944-a1bd-18f11d8b506c@oracle.com> <531f815d-01b5-8155-d0dd-4a6f53e07d53@oracle.com> From: Jason Merrill Date: Thu, 02 Nov 2017 14:42:00 -0000 Message-ID: Subject: Re: [C++ Patch] PR 80955 (Macros expanded in definition of user-defined literals) To: Mukesh Kapoor Cc: Nathan Sidwell , gcc-patches List Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00097.txt.bz2 On Wed, Nov 1, 2017 at 4:45 PM, Mukesh Kapoor wrote: > On 11/1/2017 1:02 PM, Jason Merrill wrote: >> >> On Tue, Oct 31, 2017 at 12:17 PM, Mukesh Kapoor >> wrote: >>> >>> On 10/25/2017 6:44 PM, Mukesh Kapoor wrote: >>>> >>>> On 10/25/2017 4:20 AM, Nathan Sidwell wrote: >>>>> >>>>> On 10/25/2017 12:03 AM, Mukesh Kapoor wrote: >>>>> >>>>>> Thanks for pointing this out. Checking in the front end will be >>>>>> difficult because the front end gets tokens after macro expansion. I >>>>>> think >>>>>> the difficulty of fixing this bug comes because of the requirement to >>>>>> maintain backward compatibility with the option -Wliteral-suffix for >>>>>> -std=c++11. >>>>> >>>>> >>>>> IIUC the warning's intent is to catch cases of: >>>>> printf ("some format"PRIx64 ..., ...); >>>>> where there's no space between the string literals and the PRIx64 >>>>> macro. >>>>> I suspect it's very common for there to be a following string-literal, >>>>> so >>>>> perhaps the preprocessor could detect: >>>>> >>>>> NON-FN-MACRO >>>>> >>>>> and warn on that sequence? >>>> >>>> >>>> Yes, this can be done easily and this is also the usage mentioned in the >>>> man page. I made this change in the compiler, bootstrapped it and ran >>>> the >>>> tests. The following two tests fail after the fix: >>>> >>>> g++.dg/cpp0x/Wliteral-suffix.C >>>> g++.dg/cpp0x/warn_cxx0x4.C >>>> >>>> Both tests have code similar to the following (from Wliteral-suffix.C): >>>> >>>> #define BAR "bar" >>>> #define PLUS_ONE + 1 >>>> >>>> char c = '3'PLUS_ONE; // { dg-warning "invalid suffix on literal" } >>>> char s[] = "foo"BAR; // { dg-warning "invalid suffix on literal" } >>>> >>>> Other compilers don't accept this code. Maybe I should just modify these >>>> tests to have error messages instead of warnings and submit my revised >>>> fix? >>> >>> >>> Actually, according to the man page for -Wliteral-suffix, only macro >>> names >>> that don't start with an underscore should be considered when issuing a >>> warning: >>> >>> -Wliteral-suffix (C++ and Objective-C++ only) >>> Warn when a string or character literal is followed by a >>> ud-suffix >>> which does not begin with an underscore... >>> >>> So the fix is simply to check if the macro name in is_macro() starts with >>> an >>> underscore. The function is_macro() is called only at three places. At >>> two >>> places it's used to check for the warning related to -Wliteral-suffix and >>> the check for underscore should be made for these two cases; at one place >>> it >>> is used to check for the warning related to -Wc++11-compat and there is >>> no >>> need to check for underscore for this case. >>> >>> The fix is simply to pass a bool flag as an additional argument to >>> is_macro() to decide whether the macro name starts with an underscore or >>> not. I have tested the attached patch on x86_64-linux. Thanks. >> >> Rather than add a mysterious parameter to is_macro, how about checking >> *cur != '_' before we call it? > > This is a good suggestion. I have attached the revised patch. Thanks. OK, thanks! Jason