From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) by sourceware.org (Postfix) with ESMTPS id BC8253858414; Fri, 5 Nov 2021 22:59:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BC8253858414 Received: by mail-wr1-x433.google.com with SMTP id d24so16068896wra.0; Fri, 05 Nov 2021 15:59:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=t77fnoehS8uv0tzvwuNy02sCbi9+GS1z5xbw6svhqq0=; b=PZsb6DftpL4Oe3VLCSWTDCFn8RLxaG0ghG/wNoubIfXoR6TSs72w9+fiOrFUxMNsP/ L9E4llkzEAsSfLXC9nJrP24wzZ8aU3taGye3i3WhNu2OOopHOeL1dRGRcGOe2ZPpdRvi 5oFdGDkC+rgtrfcD0ta2qicAOPmUMYjUrXx4mcVj1rDr05pyHFZ8K1l3c+pmh23yKIZx MDrgsHZ+hUXPqXnohRWbZPrZwt6Qm8SCOei1ZIEi2yZeOaHStQb/N/PVxoYgtl5PVOW1 S0iYlBMHCbxuTsXKGHbdblEeFEUEWw22c9gRfLVNObd2iEjI7rOPC04KDdq1l2gxv+P9 tnqg== X-Gm-Message-State: AOAM532lytPl74JB678LUPhI1KP1j/AXAsLCRDU5URBnjHLodFJR5q5i Le0Owze4XilIlTyHxdCItZQ= X-Google-Smtp-Source: ABdhPJz5/2UcLLq7YbVoXjXKXivG/IG7VoE33rjXEI75fYwaAq6YFcnQ4efQwiSKsOItg2+vus6iqw== X-Received: by 2002:adf:d1c2:: with SMTP id b2mr13063520wrd.369.1636153145669; Fri, 05 Nov 2021 15:59:05 -0700 (PDT) Received: from nbbrfq (dynamic-2bq7di4u2lfl4qjka9-pd01.res.v6.highway.a1.net. [2001:871:227:33a8:f6a3:c58c:7641:e771]) by smtp.gmail.com with ESMTPSA id 10sm14118262wme.27.2021.11.05.15.59.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Nov 2021 15:59:05 -0700 (PDT) Date: Fri, 5 Nov 2021 23:59:02 +0100 From: Bernhard Reutner-Fischer To: fortran@gcc.gnu.org Cc: rep.dot.nop@gmail.com, gcc-patches Subject: Re: [PATCH 0/2] incpath, Fortran: Fix memory leak in gfc_add_include_path Message-ID: <20211105235902.22a4a814@nbbrfq> In-Reply-To: <20211105211718.2261686-1-rep.dot.nop@gmail.com> References: <20211105211718.2261686-1-rep.dot.nop@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 05 Nov 2021 22:59:08 -0000 On Fri, 5 Nov 2021 22:17:16 +0100 Bernhard Reutner-Fischer wrote: > Hi! > > In order to fix this very minor leak, we need a knob to free all > cpp_dirs that were added. > This adds a free_cpp_dirs() to gcc/incpath and needs review from some > global maintainer or maybe libcpp maintainer for this hunk. One thing that i want to note is that it sounds a tiny bit odd that we (the fortran FE) pull in the usual C paths, but maybe that's deliberate and agreed on? We have in incpath.c: > /* Exported function to handle include chain merging, duplicate > removal, and registration with cpplib. */ > void > register_include_chains (cpp_reader *pfile, const char *sysroot, > const char *iprefix, const char *imultilib, > int stdinc, int cxx_stdinc, int verbose) > { > static const char *const lang_env_vars[] = > { "C_INCLUDE_PATH", "CPLUS_INCLUDE_PATH", > "OBJC_INCLUDE_PATH", "OBJCPLUS_INCLUDE_PATH" }; > cpp_options *cpp_opts = cpp_get_options (pfile); > size_t idx = (cpp_opts->objc ? 2: 0); > > if (cpp_opts->cplusplus) > idx++; > else > cxx_stdinc = false; > > /* CPATH and language-dependent environment variables may add to the > include chain. */ > add_env_var_paths ("CPATH", INC_BRACKET); > add_env_var_paths (lang_env_vars[idx], INC_SYSTEM); > > target_c_incpath.extra_pre_includes (sysroot, iprefix, stdinc); where we pass cxx_stdinc=0 and cpp_pts->cplusplus==0 (and nobody complains anout that chatty cxx_stdinc=false and not =0 but so be it) I.e. we do honor both CPATH as well as C_INCLUDE_PATH from the env for fortran preprocessing. Maybe we should document this fact somehow as i do not think we want to change it? [ in gcc/doc/cppenv.texi: @itemx OBJC_INCLUDE_PATH @c Commented out until ObjC++ is part of GCC: @c @itemx OBJCPLUS_INCLUDE_PATH where i think objc++ is currently (still) in the tree so maybe someone may want to tweak the docs here. But i digress.. ] gcc/ada/gnat_ugn.texi documents caveats for globally set C_INCLUDE_PATH when using more than one compiler. [It's the only user of :envvar:`` in the tree, everybody else seems to use @env{} btw.] I cannot judge if ada is aware of pulling in CPATH or if maybe they somehow prevent this, didn't look. Thoughts on the env vars for fortran preprocessing? thanks, > > Bootstrapped and regtested on x86_64-unknown-linux without regressions. > Ok for tunk? > > Bernhard Reutner-Fischer (2): > Add free_cpp_dirs() > Fortran: Fix memory leak in gfc_add_include_path [PR68800] > > gcc/fortran/cpp.c | 13 +++++++++++-- > gcc/fortran/cpp.h | 1 + > gcc/fortran/f95-lang.c | 2 +- > gcc/fortran/scanner.c | 7 ++++--- > gcc/incpath.c | 13 +++++++++++++ > gcc/incpath.h | 1 + > 6 files changed, 31 insertions(+), 6 deletions(-) >