> From: Joern Rennecke [mailto:joern.renne...@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
On 24 October 2014 09:06, Thomas Preud'homme wrote:
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
>> Behalf Of Joseph S. Myers
>>
>> I'm not clear if you're proposing such a patch for review, but note:
>
> Yep but not yet for inclusion as I'm waiting to see if this would suit th
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behalf Of Joseph S. Myers
>
> I'm not clear if you're proposing such a patch for review, but note:
Yep but not yet for inclusion as I'm waiting to see if this would suit the use
case of avr people.
>
> (a) you mean DEF_EXT_LIB_B
On Thu, 23 Oct 2014, Thomas Preud'homme wrote:
> Hi all,
>
> I changed the target hook somehow so that more code run in the backend
> since depending on the target (avr-libc Vs newlib) two different schemes
> are used: printf -> iprintf renaming or defining _printf_float as a
> global symbol.
Hi all,
I changed the target hook somehow so that more code run in the backend since
depending on the target (avr-libc Vs newlib) two different schemes are used:
printf -> iprintf renaming or defining _printf_float as a global symbol.
I thus renamed the target hook to match such a usage.
The pr
On Wed, 3 Sep 2014, Joern Rennecke wrote:
> On 2 September 2014 16:28, Joseph S. Myers wrote:
> > On Tue, 2 Sep 2014, Joey Ye wrote:
> >
> >> Apparently newlib is not following this specification very well, as
> >> there are symbols like _abc_r defined every where in current newlib. I
> >> am not
On 2 September 2014 16:28, Joseph S. Myers wrote:
> On Tue, 2 Sep 2014, Joey Ye wrote:
>
>> Apparently newlib is not following this specification very well, as
>> there are symbols like _abc_r defined every where in current newlib. I
>> am not implying the spec should not be followed, but is newli
> From: Joseph S. Myers [mailto:jos...@codesourcery.com]
> Sent: Tuesday, September 02, 2014 11:29 PM
>
> Identifiers beginning with a single underscore are reserved with file
> scope. This means an application cannot provide an external definition of
> them, because such an external definition w
On Tue, 2 Sep 2014, Joey Ye wrote:
> Apparently newlib is not following this specification very well, as
> there are symbols like _abc_r defined every where in current newlib. I
> am not implying the spec should not be followed, but is newlib
> designed to have a loose spec for the single undersco
On 09/02/2014 08:33 AM, Joey Ye wrote:
> On Sat, Aug 30, 2014 at 12:26 PM, Thomas Preud'homme
> wrote:
>>> From: Grissiom [mailto:chaos.pro...@gmail.com]
>>> Sent: Friday, August 29, 2014 11:51 PM
>>>
>>> Yes, it does. The namespace reserved for the implementation is _[_A-Z].
>> > The namespace
On Sat, Aug 30, 2014 at 12:26 PM, Thomas Preud'homme
wrote:
>> From: Grissiom [mailto:chaos.pro...@gmail.com]
>> Sent: Friday, August 29, 2014 11:51 PM
>>
>> Yes, it does. The namespace reserved for the implementation is _[_A-Z].
> > The namespace _[a-z] is still available for the user. Which m
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf
> Of Thomas Preud'homme
> Sent: Saturday, August 30, 2014 12:27 PM
> Mmmh indeed. I checked C99 and section 7.1.3 paragraph 1 third clause
> states:
>
> "All identifiers that begin with an underscor
> From: Grissiom [mailto:chaos.pro...@gmail.com]
> Sent: Friday, August 29, 2014 11:51 PM
>
> Yes, it does. The namespace reserved for the implementation is _[_A-Z].
> The namespace _[a-z] is still available for the user. Which means the
> user can declare their own _printf_float, and WE (as th
On 08/29/2014 10:03 AM, Eric Blake wrote:
> On 08/29/2014 09:51 AM, Grissiom wrote:
>>> Yes, it does. The namespace reserved for the implementation is _[_A-Z].
>>> The namespace _[a-z] is still available for the user. Which means the
>>> user can declare their own _printf_float, and WE (as the i
On 08/29/2014 09:51 AM, Grissiom wrote:
>> Yes, it does. The namespace reserved for the implementation is _[_A-Z].
>> The namespace _[a-z] is still available for the user. Which means the
>> user can declare their own _printf_float, and WE (as the implementation)
>> MUST NOT INTERFERE with it.
On 08/29/2014 12:04 AM, Thomas Preud'homme wrote:
>> So are you saying you are stuck with printf_float?
>
> It's not printf_float but _printf_float. I was told double underscore is only
> necessary with old toolchain as they might add a leading underscore. So
> _printf_float should not pose any k
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: Thursday, August 28, 2014 9:48 PM
> >
> > Right now I'm having trouble to define stdio_altname in newlib-c.c since
> this would
> > require it to be a C target hook but such a hook cannot be called from
> middle end.
>
> Hmm, yes,
On 28 August 2014 06:30, Thomas Preud'homme wrote:
>> Yes. I'll have to adjust the avr hook that it'll leave the v*printf /
>> v*scanf functions
>> alone - at least by default / for ISO C behaviour - but it'll give me
>> an easy way
>> to add a switch to tweak the behaviour.
>>
>> Or maybe we ca
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: Wednesday, August 27, 2014 7:54 PM
>
> Well, my goal was to have the selection be automatic for most use cases.
> That you can do a manual selection by providing -u / -l arguments to the
> linker is pretty much a given.
> Hmm, ins
On 27 August 2014 11:41, Thomas Preud'homme wrote:
>> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
>> Sent: Wednesday, August 27, 2014 6:13 PM
>>
>> I don't see how it can be any other way. We want to be able to compile
>> translation units individually, and then let the linker sort
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: Wednesday, August 27, 2014 6:13 PM
>
> I don't see how it can be any other way. We want to be able to compile
> translation units individually, and then let the linker sort out if we need
> the
> floating point enabled implement
On 27 August 2014 08:02, Thomas Preud'homme wrote:
>> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
>> Sent: Tuesday, August 26, 2014 6:44 PM
>>
>> Due to the library order defined in the specs, the float-enbled printf
>> definition will
>> be picked up from libprintf_flt.a .
>
> It se
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: Tuesday, August 26, 2014 6:44 PM
>
> Due to the library order defined in the specs, the float-enbled printf
> definition will
> be picked up from libprintf_flt.a .
It seems to me that it relies heavily on how symbol resolution wo
On 26 August 2014 07:48, Thomas Preud'homme wrote:
> What happens in the case that a program contains both some printf and
> __int_printf call?
Due to the library order defined in the specs, the float-enbled printf
definition will
be picked up from libprintf_flt.a .
> I didn't do extensive yet
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: Thursday, August 14, 2014 4:52 PM
>
> So my idea is to make the compile emit special calls when there are no
> floating
> point arguments. A library that provides the floating point enabled
> *printf/*scanf
> precedes libc in lin
> From: Joern Rennecke [mailto:joern.renne...@embecosm.com]
> Sent: Thursday, August 14, 2014 4:52 PM
>
> Newlib also has an integer-only printf implementation, but in this case,
> the default is the other way round - you have to use functions with
> nonstandard
> names to use the integer-only imp
26 matches
Mail list logo
