From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id B0E4E3835839 for ; Fri, 22 Jul 2022 01:03:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B0E4E3835839 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 26M12exD022630; Thu, 21 Jul 2022 20:02:40 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 26M12eVf022629; Thu, 21 Jul 2022 20:02:40 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 21 Jul 2022 20:02:40 -0500 From: Segher Boessenkool To: "Kewen.Lin" Cc: GCC Patches , David Edelsohn , Peter Bergner Subject: Re: [PATCH] rs6000/test: Fix empty TU in some cases of effective targets Message-ID: <20220722010240.GN25951@gate.crashing.org> References: <3d54f47a-983d-8900-7ebd-64ab55ed406c@linux.ibm.com> <20220721220912.GM25951@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no 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: Fri, 22 Jul 2022 01:03:43 -0000 Hi! On Fri, Jul 22, 2022 at 08:41:43AM +0800, Kewen.Lin wrote: > Hi Segher, > > Thanks for the comments! Always. > >> This patch is to fix empty TUs with one dummy variable definition > >> accordingly. > > > > You can also use > > enum{a}; > > which is shorter, but more importantly does not generate any code. > > You can also do > > extern int dummy; > > of course -- same idea, no definitions, only declarations. > > The used "int dummy" follows some existing practices, IMHO in this > context it doesn't matter that it will generate code or not, any of > these alternatives still generates an assembly or object file, but > the generated file gets removed after the checking. It doesn't matter here, sure. But it is certainly simple enough to make it "extern int dummy" instead, not giving a bad example for future cases where it may matter :-) > May I still keep this "int dummy" to align with existing practices? Of course, it was just advice. If things are wrong (in my opinion that is!), I'll say so. > > At least put it in #else then? Or just do things a bit more elegantly > > (do a dummy function around this for example). > > OK, since it can still emit error even without "#else", I didn't bother > to add it. I will add it, and update the "nope no good" to "#error > doesn't have float128 support". Just say === void nope (void) { #ifndef __FLOAT128__ nope no good #endif } === which works in all cases? Less maintenance is a good thing :-) Segher