Re: *-rtems and binutils 2.14.92

[Joel Sherrill <joel dot sherrill at OARcorp dot com>]

Daniel Jacobowitz wrote:

> On Tue, May 11, 2004 at 12:48:42PM -0500, Joel Sherrill wrote:
>
> > Hi,
> >
> > I have managed to build the following targets with 2.14.92
> > on a Linux host.
> >
> >  arm-rtems4.7		  h8300-rtems4.7
> >  i386-rtems4.7		  i960-rtems4.7
> >  m68k-rtems4.7		  mips64-rtems4.7
> >  mips-rtems4.7		  powerpc-rtems4.7
> >  sh-rtems4.7		  sh-rtemself4.7
> >  sparc-rtems4.7	  tic4x-rtems4.7
> >
> > I could not successfully build or32-rtems.  I do not know if
> > any or32 target is expected to build.
>
>
> or32-elf had only 3 LD testsuite failures, according to Nick's posted
> results, so this may be a configury issue.

OK.  or32-rtems should just be an alias for or32-elf so
that gcc can recognize it as a slightly different target.
I am posting a simple patch to address that.  Hopefully
someone will apply it. :)


> > I am in the process of building all RTEMS configurations with
> > those binutils and gcc 3.3.3/newlib 1.11.0.  Those were built
> > using binutils 2.14 if that matters to anyone.  I am midway
> > in the m68k in building RTEMS but wanted to pass this much
> > along:
> >
> > h8300 - bad expression error on file compiled by gcc with
> >  "-mh -mint32" is that helps.
> >
> > I trimmed the assembly language down to this:
> >
> >       .h8300h
> >        .section .text
> >        cmp.l   #--2147483648,er2
> >
> > gcc invoked gas with only --traditional-format as an
> > argument -- there were no CPU flag options if that matters.
> >
> > Hmmm... that "--" shouldn't be there.  Is this a gcc 3.3.3 bug
> > that only a newer binutils has caught?  Does anyone recognize it?
>
>
> I believe that the -- used to be parsed as - ( - 2147483648 ), and
> Nathan added a patch to prevent this because most people expected --
> and ++ to mean some sort of increment/decrement.  Certainly the
> expression above doesn't make much sense; that's -MIN_INT ....

So you would consider this a gcc bug?

--joel