Internal compiler error building m68k.

Rob Landley rob at landley.net
Wed Oct 1 17:19:02 UTC 2008


On Wednesday 01 October 2008 02:47:38 Bernhard Reutner-Fischer wrote:
> On Tue, Sep 30, 2008 at 07:06:14PM -0700, Khem Raj wrote:
> >On Tue, Sep 30, 2008 at 12:12 AM, Bernhard Reutner-Fischer
> >
> ><rep.dot.nop at gmail.com> wrote:
> >> On Mon, Sep 29, 2008 at 09:28:57PM -0500, Rob Landley wrote:
> >>>On Monday 29 September 2008 10:56:04 Bernhard Reutner-Fischer wrote:
> >>>> On Sun, Sep 28, 2008 at 11:55:53AM -0500, Rob Landley wrote:
> >>>> >So with the attached .config, building last night's svn snapshot, is
> >>>> > anybody else seeing this:
> >>>> >
> >>>> >libc/inet/addr.c: In function 'inet_ntoa_r':
> >>>> >libc/inet/addr.c:144: internal compiler error: in output_move_qimode,
> >>>> > at config/m68k/m68k.c:1827
> >
> >Hi Rob,
> >
> >If you hit a GCC ICE I think it is good to open a bug for it in gcc
> >bugzilla. If it worked on stable releases and ICE'es on svn trunk then
>
> Khem, his compiler is definitely _not_ a stable release. Remember that
> the 4.1 branch is closed, dead and burried.

A compiler released on February 13, 2007 is dead and buried, so says a project 
that last had _any_ stable release on May 6, 2007.  Uh-huh.

As I said before, it also occurred exactly the same way in 4.2.  The stable 
compiler shipping with Ubuntu 8.04 is 4.2.3.  If your definition of "closed, 
dead, and buried" includes the default compiler that comes with the most 
recent release of the most widely used Linux distro, It's not a very useful 
definition.

> It seems to work for me with 
> the current stable release (i.e. 4.3.2) for m68k.

Good for you.  Can you statically compile an arm soft float program?  (I.E. 
did they finally add the soft float stuff to libgcc.a in addition to 
libgcc_s.so without patching the gcc build?)

> ISTR that m68k is not a primary platform but i don't have the list at
> hand.

This internal compiler error has been occurring for me since before 4.3 came 
out.  It seems that avoiding triggering it in uClibc might be a good idea, if 
anybody was actually using uClibc on m68k, which does not appear to be the 
case.

Rob



More information about the uClibc mailing list