From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from re-prd-fep-042.btinternet.com (mailomta9-re.btinternet.com [213.120.69.102]) by sourceware.org (Postfix) with ESMTPS id 34486385802B for ; Thu, 21 Oct 2021 13:08:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 34486385802B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from re-prd-rgout-001.btmx-prd.synchronoss.net ([10.2.54.4]) by re-prd-fep-042.btinternet.com with ESMTP id <20211021130849.BEIC12369.re-prd-fep-042.btinternet.com@re-prd-rgout-001.btmx-prd.synchronoss.net> for ; Thu, 21 Oct 2021 14:08:49 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 613A8CC305E89804 X-Originating-IP: [81.129.146.209] X-OWM-Source-IP: 81.129.146.209 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvtddrvddviedgiedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecunecujfgurhepufhfhffvkffffgggjggtgfesthejredttdefjeenucfhrhhomheplfhonhcuvfhurhhnvgihuceojhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukheqnecuggftrfgrthhtvghrnhepkeeihedvtedugeeuueetieekuefhgfdvjeetffevlefgueeiheffjedtvdeggfeknecuffhomhgrihhnpehsthgrtghkohhvvghrfhhlohifrdgtohhmnecukfhppeekuddruddvledrudegiedrvddtleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddruddtfegnpdhinhgvthepkedurdduvdelrddugeeirddvtdelpdhmrghilhhfrhhomhepjhhonhdrthhurhhnvgihsegurhhonhgvtghouggvrdhorhhgrdhukhdprhgtphhtthhopegthihgfihinhdquggvvhgvlhhophgvrhhssegthihgfihinhdrtghomh X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.103] (81.129.146.209) by re-prd-rgout-001.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 613A8CC305E89804 for cygwin-developers@cygwin.com; Thu, 21 Oct 2021 14:08:49 +0100 Subject: Re: automake issue References: <620fad2f-74b0-4a39-45e0-bb2acc00129e@cornell.edu> From: Jon Turney To: cygwin-developers@cygwin.com Message-ID: Date: Thu, 21 Oct 2021 14:08:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1192.7 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, 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: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2021 13:08:54 -0000 On 21/10/2021 11:48, Corinna Vinschen wrote: > On Oct 20 16:58, Ken Brown wrote: >> I was debugging with what I thought was an unoptimized build of cygwin1.dll >> (with -O0 in CXXFLAGS), but then I discovered that malloc.cc was actually >> compiled with -O3. This is because of the following snippet from >> winsup/cygwin/Makefile.am: >> >> # If an optimization level is explicitly set in CXXFLAGS, set -O3 for these files >> # XXX: this seems to assume it's not -O0? Note that this is my observation of a pre-existing issue, not something that's introduced by the automake conversion. >> # >> # (the indentation here prevents automake trying to process this as an automake >> # conditional) >> ifneq "${filter -O%,$(CXXFLAGS)}" "" >> malloc_CFLAGS=-O3 >> sync_CFLAGS=-O3 >> endif >> >> I thought I could fix this by changing the snippet to >> >> ifneq "${filter -O%,$(CXXFLAGS)}" "" >> ifeq "${filter -O0,$(CXXFLAGS)}" "" >> malloc_CFLAGS=-O3 >> sync_CFLAGS=-O3 >> endif >> endif Clever. It didn't occur to me to write something like this. >> but this didn't work. After running winsup/autogen.sh, >> winsup/cygwin/Makefile.in contained >> >> malloc_CFLAGS = -O3 >> sync_CFLAGS = -O3 >> >> unconditionally. Hmm.. yes. That's disappointing. I think it was working at some stage, so idk if this is a automake change? >> So in spite of the comment above about indentation, it seems that the >> conditional is being treated as an automake conditional. >> >> Does anyone know how to fix this so that -O0 really produces an unoptimized build? > > I workaround this by setting CFLAGS=-g on the command line. There's no > -O then and it should work as desired. The save thing would probably > be something like this, though: > > https://stackoverflow.com/questions/4256609/makefile-conditional-with-automake-autoconf Using an automake conditional isn't good, because that can't consider the value of CXXFLAGS if it's overriden on the 'make' command line. Really, I'm not sure if this block is a good idea at all. I did consider removing it when converting to automake. I couldn't find any history which suggests these flags are here due to evidence ('using -O3 makes this benchmark faster'), rather than guesswork ('these files probably contain hotspots, so use -O3 to make it go faster!').