RE: selective linking of floating point support for *printf / *scanf

["Thomas Preud'homme" <thomas dot preudhomme at arm dot com>]

> From: Joern Rennecke [mailto:joern.rennecke@embecosm.com]
> Sent: Sunday, November 02, 2014 4:34 PM
> 
> 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.

> 
> 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:
> 
> + exp = copy_node (exp);
> + CALL_EXPR_FN (exp) = build_addr (decl, current_function_decl);
> 
> 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.

> 
> 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 auto).
Isn't it possible to define different default value for different backend?

> 
> 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 can
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