This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA:] Don't use multilib strings in libgloss/m32r/trapmon0.c




Thanks Jeff.  Privately, an RTEMS user sent me the C99 standard
section that disallows this but no one on the gcc list ever
bothered to cite it and say what you did. 

Now I will go back under my rock and try to help fix this
across the board. :(

--joel



"J. Johnston" wrote:
> 
> Joel Sherrill wrote:
> >
> > "J. Johnston" wrote:
> > >
> > > Hans-Peter Nilsson wrote:
> > > >
> > > > Multi-line string literals are deprecated in gcc-3.1 and are
> > > > removed from GCC trunk, so some fix is needed.  Here's one I've
> > > > been using for a while.  Please tell if ok to commit.
> > > >
> > > > libgloss:
> > > > 2002-04-13  Hans-Peter Nilsson  <hp@bitrange.com>
> > > >
> > > >         * m32r/trapmon0.c (__trap0): Don't use multi-line strings.
> > > >
> > > >
> > >
> > > Checked in.  Thanks.  The change to gcc is going to be a major pain for embedded developers.
> >
> > I couldn't agree more.  I found 1000s of asm statements in a quick
> > grep of newlib, RTEMS, and gdb. :(  Hopefully most are single liners.
> >
> > I accept the fact that we all are going to have to do this but ..
> >
> > Could someone explain to me why this is a useful change technically?
> >
> 
> It isn't a useful change.  IMO, the asm construct is an extension to the
> language and need not follow any ANSI format.  As it turns out, the multi-line string
> was allowed in general and the compiler does not distinguish the rules inside the
> asm construct.  When they decided to shut it off, the use of it everywhere, including
> the asm construct got hit.
> 
> > And is there anyway short of brute force to address this?
> >
> 
> Not that I know of.  I don't think it is easy for the compiler to add such support
> just for the asm context.  The deadline to get this done is by gcc 3.2 where it becomes
> an error.
> 
> -- Jeff J.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]