On Wed, Oct 1, 2008 at 10:19 AM, Rob Landley <[EMAIL PROTECTED]> wrote: > 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 >> > >> ><[EMAIL PROTECTED]> 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 >
all I am interested is if it happen on gcc trunk then its interesting. _______________________________________________ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
