[RFA:] Fix libgloss/d30v/syscalls.c

Joel Sherrill joel.sherrill@OARcorp.com
Tue Apr 16 04:04:00 GMT 2002

Thanks.  You are using the same criteria for picking
them I am. Compile some and see what breaks. :)

I will follow your lead by inserting a couple of tabs
and then \n\.


Hans-Peter Nilsson wrote:
> On Mon, 15 Apr 2002, Joel Sherrill wrote:
> > I am starting to wade through some targets and wanted
> > to make sure I did it the right way.
> >
> > Is there any standard on what we want on the right hand
> > side?  I see Hans is tab'ing out a few and then putting
> > \n\.
> That was just a matter of taste for the moment or something.  I
> wouldn't have been surprised or anything if Jeff had chosen to
> tweak it to fit his taste.  Though generally using \n\ instead
> of \n" and string concatenation would avoid warnings (when such
> warnings are enabled) about string concatenation being one of
> those new-fangled ISO C features from '89. :-)
> Please, whatever you do, just don't use ';' as a line-terminator
> to split instructions, because it's not universally working.
> People would be surprised and annoyed if they copy that, only to
> later find out that ';' is a comment character for the
> architecture they tweaked asms for.  Newline-tab on the other
> hand *is* universal.  Else GCC wouldn't work at all.
> > Hans.. do you have an order you are working through the
> > files in?  I want to work on a different subset than you.
> They're all yours; I don't plan on fixing more.  I just stumbled
> on these, because m32r worked before the multiline-string change
> (see <URL:http://gcc.gnu.org/simtest-howto.html> -- the other
> targets at least compiles beyond libgloss+newlib), and RTH fixed
> enough bugs that the d30v problems were uncovered (see
> <URL:http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00621.html>).
> > How are you testing before you submit your patches?
> m32r builds and runs as a simulator target.  d30v builds beyond
> libgloss/d30v/syscalls.c; it ICE:s in libstdc++-v3.  The
> formatting I did in syscalls.c should be trivial enough to not
> disturb functionality provided that the file was right before.
> brgds, H-P

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

More information about the Newlib mailing list