[patch] newlib long long printf for rtems

[Joel Sherrill]

"Fernando RUIZ CASAS (E-mail)" wrote:
> 
> > -----Mensaje original-----
> > De: Nick Clifton [mailto:nickc at redhat.com]
> > Enviado el: jueves, 04 de enero de 2001 2:25
> > Para: aaron at frye.com
> > CC: binutils at sources.redhat.com; rtems-users at oarcorp.com;
> > newlib at sources.redhat.com
> > Asunto: Re: [patch] newlib long long printf for rtems
> >
> >
> > Hi Aaron,
> >
> > : I asked Joel Sherrill about it on the rtems-users list:
> > :
> > : > is there any reason why newlib doesn't enable long long support in
> > : > printf for RTEMS?
> > :
> > : to which Joel replied:
> > :
> > : > Very simple, it was overlooked and no one noticed until now. :)
> > : >
> > : > Submit a patch.
> > :
> > : so I did.
> >
> > Fair enough - I was just asking.  I am not the official maintainer for
> > newlib (that would be Jeff Johnston <jjohnstn at redhat.com>) but I ran
> > across this same problem for a different toolchain so I was interested
> > to know if there were any expected problems.
> >
> > : for future reference, should all rtems-specific patches be sent
> > : through Joel?
> >
> > Sorry I do not know.  My guess would be that having them discussed on
> > the rtems-users list would be the right thing to do first, and once
> > they are ready submitting them to the appropriate mailing list
> > (newlib at sources.redhat.com in this particular case).
> >
> >
> > Cheers
> >       Nick
> >
> 
> And all the patches when GCC 3.0? (Soon)

I have submitted all RTEMS patches to gcc and most are already in.
Help shepherding them through the process is always appreciated.

newlib 1.9.0 is extremely close (one file to remove from CVS)
and I believe that is fixed in the repository.

binutils CVS should be fine for RTEMS.

gdb needs work as I said in the other email (kick myself again).

> Is redhat & gnu thinking in RTEMS?

It is the RTEMS community's responsibility to get patches submitted.
We must shepherd them through and really there should be some more
volunteer effort in testing/following up with CVS versions of the
tools.
 
> We are a tree independent from gcc & gnu.

Not really.  We just have patches to official GNU releases to address
specific problems/additions from our community.  Our patches (ignoring
gdb) tend to be very small and "point oriented".

> All mistakes from gcc must be sended to gcc but we need now the patch for
> RTEMS.

If you encounter a real code generation problem with gcc, by all means 
submit it there but if it is a real problem, we want it in the general
RTEMS patch so our prebuilt binaries are correct.
 
> Fist submit the ideas & pathches to Joel and discuss them in the list.
> At last, Joel publish the patch in repository if this a good idea.
> 
> This is my opinion.

That's basically how it works now.  I would like to share the
responsibility.
In particular, gating all patches through me produces delays at times
that even I find offensive. :)
 
> Saludos from Spain.
> Fernando RUIZ CASAS
> 
> fernando.ruiz at ctv.es
> correo at fernando-ruiz.com
> 
> P.D.:
> 
> In IAR printf sources have a good MACRO
> 
> NO_FLOATS
> FLOATS_REDUCED
> FLOATS_INCLUDED
> 
> In this concern we can add
> 
> LONG_FLOATS included.
> 
> With this a tiny,small,compact,normal or extended system can be builded and
> everybody will be very happy.
> 
> Setting the configuration in  'user.cfg' ready.

newlib has somethings like this as well.  You can use iprintf()
to avoid having floating point at all.

> ./bit makes it automaticaly.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985