From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id CD1CE3857B97 for ; Sun, 29 May 2022 19:54:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CD1CE3857B97 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-224-TbCJ8MhtMiaKz32i5wSuOQ-1; Sun, 29 May 2022 15:54:17 -0400 X-MC-Unique: TbCJ8MhtMiaKz32i5wSuOQ-1 Received: by mail-qk1-f197.google.com with SMTP id br42-20020a05620a462a00b006a5b92ed7b2so6961193qkb.19 for ; Sun, 29 May 2022 12:54:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=B8K0YES00lj2zmVyOhiCYtA402JtpnKSVxa5857bYxQ=; b=f80h+CQ8JM6LdnHeyvHpFpphT96YChkXsSoMQmy/vbllV8jA4AnchPCJLdHPOjq/T+ mwQBW9VPCek9n65bKuP6dAl8M2ozcXnyiKIYdC5ujJ0Rzvuhu8IzGGXsVqtW+dMSuBYk dJgSNaC3Px96d6KpRB/FOkmXQ7rHFwltINyc4/YdvwWPOvwGZKzU4fo/XV7Pjm2YQOXX 6xvKA6fTiEwQSYMDJkRf/7R0O8ZJs8oG5x920bxWTWmn1zev0e9WiGMThyzAEhuKMi/4 WPYjf005qDYy7gRP2IkfJwkzd7+lt2vwW9BjMjHkl71V8tBJ8Sqk7PF/Hr+Q3a3S3P+M JNMQ== X-Gm-Message-State: AOAM532u2X9J0JTJEH9Ki0Q9ZztLaC6KIE7iiisobinHJSji7meR+0t0 sAZMPsZEDHj4n0z5WrrU3vDpIcJzDfjEC9XIEzJgVnscw9IY50oDg6VG7/OVvBxz0Pcm6vhrfRy K48CXyYbrkjseLX10+Q== X-Received: by 2002:ad4:5cee:0:b0:464:53bb:a299 with SMTP id iv14-20020ad45cee000000b0046453bba299mr177542qvb.92.1653854057075; Sun, 29 May 2022 12:54:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwtyg5P+qstHAkU8whoxl+IiQaIRwOBG2Y4KvZfJkEfwwQ3B9C09T14KI+XJb0Q3t2WtyZNpg== X-Received: by 2002:ad4:5cee:0:b0:464:53bb:a299 with SMTP id iv14-20020ad45cee000000b0046453bba299mr177526qvb.92.1653854056718; Sun, 29 May 2022 12:54:16 -0700 (PDT) Received: from [192.168.1.100] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id w8-20020a05620a148800b006a60190ed0fsm2992539qkj.74.2022.05.29.12.54.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 May 2022 12:54:16 -0700 (PDT) Message-ID: Date: Sun, 29 May 2022 15:54:15 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH] libcpp: Ignore CPP_PADDING tokens in _cpp_parse_expr [PR105732] To: Jakub Jelinek , "Joseph S. Myers" , Marek Polacek Cc: gcc-patches@gcc.gnu.org References: From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2022 19:54:21 -0000 On 5/27/22 04:16, Jakub Jelinek wrote: > Hi! > > The first part of the following testcase (m1-m3 macros and its use) > regressed with my PR89971 fix, but as the m1,m4-m5 and its use part shows, > the problem isn't new, we can emit a CPP_PADDING token to avoid it from > being adjacent to whatever comes after the __VA_OPT__ (in this case there > is nothing afterwards, true). > > In most cases these CPP_PADDING tokens don't matter, all other > callers of cpp_get_token_with_location either ignore CPP_PADDING tokens > completely (e.g. c_lex_with_flags) or they just remember them and > take them into account when printing stuff whether there should be > added whitespace or not (scan_translation_unit + token_streamer::stream). > So, I think we should just ignore CPP_PADDING tokens the same way in > _cpp_parse_expr. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. > 2022-05-27 Jakub Jelinek > > PR preprocessor/105732 > * expr.cc (_cpp_parse_expr): Handle CPP_PADDING by just another > token. > > * c-c++-common/cpp/va-opt-10.c: New test. > > --- libcpp/expr.cc.jj 2022-01-18 11:59:00.258972399 +0100 > +++ libcpp/expr.cc 2022-05-26 15:39:54.348780446 +0200 > @@ -1366,6 +1366,10 @@ _cpp_parse_expr (cpp_reader *pfile, bool > op.op = CPP_UMINUS; > break; > > + case CPP_PADDING: > + lex_count--; > + continue; > + > default: > if ((int) op.op <= (int) CPP_EQ || (int) op.op >= (int) CPP_PLUS_EQ) > SYNTAX_ERROR2_AT (op.loc, > --- gcc/testsuite/c-c++-common/cpp/va-opt-10.c.jj 2022-05-26 15:54:40.279766330 +0200 > +++ gcc/testsuite/c-c++-common/cpp/va-opt-10.c 2022-05-26 15:54:24.028928687 +0200 > @@ -0,0 +1,18 @@ > +/* PR preprocessor/105732 */ > +/* { dg-do compile } */ > +/* { dg-options "-std=gnu99" { target c } } */ > +/* { dg-options "-std=c++20" { target c++ } } */ > + > +#define m1(p1, p2, p3) p3 > +#define m2(p1, ...) 1##__VA_OPT__(foo) > +#define m3(...) m1(1, 2, m2) > +#define m4(p1, ...) 1 __VA_OPT__() > +#define m5(...) m1(1, 2, m4) > +#if m3(,)(,) > +#else > +#error > +#endif > +#if m5(,)(,) > +#else > +#error > +#endif > > Jakub >