*-rtems and binutils 2.14.92

[Joel Sherrill]

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