From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32264 invoked by alias); 12 Nov 2014 18:08:39 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 32254 invoked by uid 89); 12 Nov 2014 18:08:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Nov 2014 18:08:36 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Wed, 12 Nov 2014 18:08:31 +0000 Received: from SHAWIN202 ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Nov 2014 18:08:29 +0000 From: "Thomas Preud'homme" To: "'Joern Rennecke'" Cc: "Joseph S. Myers" , "GCC" , "Joerg Wunsch" , , "Andrew Burgess" , References: <001401cfc0f9$bdc5cbc0$39516340$@arm.com> <001901cfc1c4$d0678630$71369290$@arm.com> <000001cfc1e3$7f1a22f0$7d4e68d0$@arm.com> <000101cfc281$3a3008f0$ae901ad0$@arm.com> <000201cfc34f$1ceadb20$56c09160$@arm.com> <000801cfee9e$47919380$d6b4ba80$@arm.com> <000c01cfef61$6316d2a0$294477e0$@arm.com> In-Reply-To: Subject: RE: selective linking of floating point support for *printf / *scanf Date: Wed, 12 Nov 2014 18:08:00 -0000 Message-ID: <001301cffea3$a796b570$f6c42050$@arm.com> MIME-Version: 1.0 X-MC-Unique: 114111218083105701 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2014/txt/msg00584.txt.bz2 > From: Joern Rennecke [mailto:joern.rennecke@embecosm.com] > Sent: Sunday, November 02, 2014 4:34 PM >=20 > Sorry for the late reply, I was on vacation, and then I meant to flesh > out a suitable > solution for the macro/hook problem to test it, but the more I think > about it, the more > questions arise how this is best structured... No problem, I'm pretty busy myself with other stuff as well. >=20 > First, the interface of your hook: you say it returns a bool, but that > bool is not used. Indeed. I just though it could be used later but since it's an internal interface it could be removed for now and added later. > You leave the case to fall through to the default case, thus emitting > the expression unchanged. > For my purposes, I have to change the expression. Oh yes my apologize. The hook should return the next expression. > Note how my original patch had: >=20 > + exp =3D copy_node (exp); > + CALL_EXPR_FN (exp) =3D build_addr (decl, current_function_decl); >=20 > I don't think changing the existing expression > destructively is safe, so the return value should be the - possibly > changed - expression. > You can just explain in the hook description that this return value > may be changed and/or > additional target-specific output may be emitted. Agreed. >=20 > The auto-float-io option description dos not match what I intended the > hook to do on the > avr. The idea was to have standard behaviour as default, i.e. printf > knows about float, and > have the hook change the function name to the integer-specific > function if the arguments > don't mention float and the function is not a v* function. Changing the default to auto-float-io should be ok. All we need is a way to build newlib without this option since newlib contains some call to vprintf and this would define the _printf_float symbol (and thus pulling code to printf float) in any program using newlib. Having the default to be off would ease the transition. It would be possible to add the -fno-auto-float-io switch automatically in newlib when gcc is detected to be recent enough but then compiling old newlib with a recent gcc would always pull support for printing float values. > So, if we want to have a versatile hook and describe the option > specifically, it should be > a target option. OTOH, that complicate the implementation of a > generic hook even more... Well the hook doesn't have to be different, just the default (auto Vs no au= to). Isn't it possible to define different default value for different backend? >=20 > targhooks.c is not entirely target-independent code, so on one level > we could say it's > OK to customize it with macros, and we don't want to stuff the target > vector with a gazillion > settings that only very few targets use, but OTOH, if one target has > multiple libraries, > it might want multile variants of this hook. In fact, having > sub-hooks for that hook wouldn't > work if they were POD-kind hooks, and way overcomplicate the target if > they weren't... [SNIP explanation of how to do it with hook with template] This all look complicated when in fact what we want is C target hook that c= an be invoked from the middle end. Couldn't we use some kind of weak symbol so that when no C library is linked in it compiles but nothing happens? Thanks for all your comments Joern. Much appreciated. Best regards, Thomas