From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5400 invoked by alias); 31 May 2019 08:50:01 -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 5279 invoked by uid 89); 31 May 2019 08:50:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-lf1-f65.google.com Received: from mail-lf1-f65.google.com (HELO mail-lf1-f65.google.com) (209.85.167.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 May 2019 08:49:58 +0000 Received: by mail-lf1-f65.google.com with SMTP id r15so7244427lfm.11 for ; Fri, 31 May 2019 01:49:58 -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=w3tn1j1VSVCean8YCb2a+neHeLacpPXFMp+ag8uyrv8=; b=Qc+XJWjZgRyb4bv1OZuKlGViTQmMwRsRevK28QC6b82K/U28DxW+dpm0Elrjsvah9c 217xlJzAJRg4G8T9NXMMsfnSZxmLhJ6xUtSfebxv7i1guaeosWbXOjq5EqjwW5VUA946 WJe3y5W+qFMiAYDDnb3undcf4XfRVCP4N2hMTGOIx4FHKW5ZxplY7tlVP3gQESRLqSGF 6BfyXQcvBtjFtf+ulYcnDetZi20MB2SnH6ZFIP+qgSsSKhoj/d7Y0IBhqjGCl2pdgK1H dc7bluBqjvQJ6FxwCydVulp5UOvjaCr6y5z/N1QwHoYaREQFHfC/2czuZztySeZ8c90P Em+Q== MIME-Version: 1.0 References: <1559249198.2997.159.camel@redhat.com> In-Reply-To: <1559249198.2997.159.camel@redhat.com> From: Richard Biener Date: Fri, 31 May 2019 09:01:00 -0000 Message-ID: Subject: Re: [PATCH][Preprocessor]patch to fix PR 90581 To: David Malcolm Cc: Qing Zhao , gcc Patches , bernhard Reutner-Fischer Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg02095.txt.bz2 On Thu, May 30, 2019 at 10:46 PM David Malcolm wrote: > > On Thu, 2019-05-30 at 11:23 -0500, Qing Zhao wrote: > > Hi, > > > > PR 90581 (provide an option to adjust the maximum depth of nested > > #include) > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581 > > > > is to add a new cpp option -fmax-inlcude-depth to set the maximum > > depth of nested #include. > > > > '-fmax-include-depth=DEPTH' > > Set the maximum depth of the nested include. The default value > > is > > 200. > > > > Please check the attached patch. > > I have done bootstrap and regression test on X86, no any issue. > > > > thanks a lot. > > > > Qing. > > > Thanks for working on this. It's looking promising, but I agree that a > param would be better than an option. Not sure - this is for language limits and we do have existing like -ftemplate-backtrace-limit and -ftemplate-depth. > One idea that occurred to me looking at the patch... > > > index 3ee8bc4..480c282 100644 > > --- a/libcpp/directives.c > > +++ b/libcpp/directives.c > > @@ -831,7 +831,7 @@ do_include_common (cpp_reader *pfile, enum include_type type) > > } > > > > /* Prevent #include recursion. */ > > - if (pfile->line_table->depth >= CPP_STACK_MAX) > > + if (pfile->line_table->depth >= CPP_OPTION (pfile, max_include_depth)) > > cpp_error (pfile, CPP_DL_ERROR, "#include nested too deeply"); > > ...a nice usability tweak here would be to give a hint about the new > param, to give the user an idea on how to increase the limit. > > Maybe something like: > > cpp_error (pfile, CPP_DL_ERROR, > "%<#include%> nested too deeply (depth %i);" > " use %<--param max-include-depth=LIMIT%> to support deeper nesting", > pfile->line_table->depth); > > (though probably that would be better as a followup "note") > > Dave