Re: failuer to build uberbaum --target=m68k-elf

Re: failuer to build uberbaum --target=m68k-elf

[Peter Barada]

I'm trying to build the uberbaum tree, configured as:

[peter@baradas obj]$ cat config.status 
#!/bin/sh
# This file was generated automatically by configure.  Do not edit.
# This directory was configured as follows:
/home/peter/work/cvs-gnu/uberbaum/configure --with-gcc-version-trigger=/home/peter/work/cvs-gnu/uberbaum/gcc/version.c --host=i686-pc-linux-gnu --target=m68k-elf --prefix=/home/mylocal/uberbaum/m68k-elf --norecursion 
# 
[peter@baradas obj]$ 

And it fails building newlib with:


/home/peter/work/cvs-gnu/obj/gcc/xgcc -B/home/peter/work/cvs-gnu/obj/gcc/ -nostdinc -B/home/peter/work/cvs-gnu/obj/m68k-elf/m68000/newlib/ -isystem /home/peter/work/cvs-gnu/obj/m68k-elf/m68000/newlib/targ-include -isystem /home/peter/work/cvs-gnu/uberbaum/newlib/libc/include -B/home/mylocal/uberbaum/m68k-elf/m68k-elf/bin/ -B/home/mylocal/uberbaum/m68k-elf/m68k-elf/lib/ -isystem /home/mylocal/uberbaum/m68k-elf/m68k-elf/include -L/home/peter/work/cvs-gnu/obj/ld  -m68000 -DPACKAGE=\"newlib\" -DVERSION=\"1.10.0\"  -I. -I/home/peter/work/cvs-gnu/uberbaum/newlib/libm/math  -I/home/peter/work/cvs-gnu/uberbaum/newlib/libm/math/../common -O2 -DCOMPACT_CTYPE -DMISSING_SYSCALL_NAMES -fno-builtin      -O2 -g -O2  -m68000 -c /home/peter/work/cvs-gnu/uberbaum/newlib/libm/math/kf_cos.c
/home/peter/work/cvs-gnu/uberbaum/newlib/libm/math/kf_cos.c: In function `__kernel_cosf':
/home/peter/work/cvs-gnu/uberbaum/newlib/libm/math/kf_cos.c:59: internal compiler error: in trunc_int_for_mode, at explow.c:56
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[7]: *** [kf_cos.o] Error 1
make[7]: Leaving directory `/home/peter/work/cvs-gnu/obj/m68k-elf/m68000/newlib/libm/math'
make[6]: *** [all-recursive] Error 1
make[6]: Leaving directory `/home/peter/work/cvs-gnu/obj/m68k-elf/m68000/newlib/libm'
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory `/home/peter/work/cvs-gnu/obj/m68k-elf/m68000/newlib'
make[4]: *** [all-recursive-am] Error 2
make[4]: Leaving directory `/home/peter/work/cvs-gnu/obj/m68k-elf/m68000/newlib'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory `/home/peter/work/cvs-gnu/obj/m68k-elf/newlib'
make[2]: *** [all-multi] Error 2
make[2]: Leaving directory `/home/peter/work/cvs-gnu/obj/m68k-elf/newlib'
make[1]: *** [all-recursive-am] Error 2
make[1]: Leaving directory `/home/peter/work/cvs-gnu/obj/m68k-elf/newlib'
make: *** [all-target-newlib] Error 2
[peter@baradas obj]$ 

See also:
http://gcc.gnu.org/ml/gcc/2002-12/msg00133.html

1) Am I attempting to configure and biuld the uberbaum tree correctly?
2) Has *anyone* else seen this?
3) Any suggestions where I should look from here?

All help is appreciated.

-- 
Peter Barada
peter@baradas.org

Re: failuer to build uberbaum --target=m68k-elf

[Hans-Peter Nilsson]

On Fri, 20 Dec 2002, Peter Barada wrote:
> /home/peter/work/cvs-gnu/obj/gcc/xgcc -B/home/peter/work/cvs-gnu/obj/gcc/ -nostdinc -B/home/peter/work/cvs-gnu/obj/m68k-elf/m68000/newlib/ -isystem /home/peter/work/cvs-gnu/obj/m68k-elf/m68000/newlib/targ-include -isystem /home/peter/work/cvs-gnu/uberbaum/newlib/libc/include -B/home/mylocal/uberbaum/m68k-elf/m68k-elf/bin/ -B/home/mylocal/uberbaum/m68k-elf/m68k-elf/lib/ -isystem /home/mylocal/uberbaum/m68k-elf/m68k-elf/include -L/home/peter/work/cvs-gnu/obj/ld  -m68000 -DPACKAGE=\"newlib\" -DVERSION=\"1.10.0\"  -I. -I/home/peter/work/cvs-gnu/uberbaum/newlib/libm/math  -I/home/peter/work/cvs-gnu/uberbaum/newlib/libm/math/../common -O2 -DCOMPACT_CTYPE -DMISSING_SYSCALL_NAMES -fno-builtin      -O2 -g -O2  -m68000 -c /home/peter/work/cvs-gnu/uberbaum/newlib/libm/math/kf_cos.c
> /home/peter/work/cvs-gnu/uberbaum/newlib/libm/math/kf_cos.c: In function `__kernel_cosf':
> /home/peter/work/cvs-gnu/uberbaum/newlib/libm/math/kf_cos.c:59: internal compiler error: in trunc_int_for_mode, at explow.c:56

> 2) Has *anyone* else seen this?

Also spotted on the 3.3 branch, LAST_UPDATED Tue Dec 17 17:49:08
GMT 2002

> 3) Any suggestions where I should look from here?

Besides running cc1 in gdb and finding out where the offending
trunc_int_for_mode call comes from? ;-)

brgds, H-P

Re: failuer to build uberbaum --target=m68k-elf

[Peter Barada]

>On Fri, 20 Dec 2002, Peter Barada wrote:
>> /home/peter/work/cvs-gnu/obj/gcc/xgcc -B/home/peter/work/cvs-gnu/obj/gcc/ -nostdinc -B/home/peter/work/cvs-gnu/obj/m68k-elf/m68000/newlib/ -isystem /home/peter/work/cvs-gnu/obj/m68k-elf/m68000/newlib/targ-include -isystem /home/peter/work/cvs-gnu/uberbaum/newlib/libc/include -B/home/mylocal/uberbaum/m68k-elf/m68k-elf/bin/ -B/home/mylocal/uberbaum/m68k-elf/m68k-elf/lib/ -isystem /home/mylocal/uberbaum/m68k-elf/m68k-elf/include -L/home/peter/work/cvs-gnu/obj/ld  -m68000 -DPACKAGE=\"newlib\" -DVERSION=\"1.10.0\"  -I. -I/home/peter/work/cvs-gnu/uberbaum/newlib/libm/math  -I/home/peter/work/cvs-gnu/uberbaum/newlib/libm/math/../common -O2 -DCOMPACT_CTYPE -DMISSING_SYSCALL_NAMES -fno-builtin      -O2 -g -O2  -m68000 -c /home/peter/work/cvs-gnu/uberbaum/newlib/libm/math/kf_cos.c
>> /home/peter/work/cvs-gnu/uberbaum/newlib/libm/math/kf_cos.c: In function `__kernel_cosf':
>> /home/peter/work/cvs-gnu/uberbaum/newlib/libm/math/kf_cos.c:59: internal compiler error: in trunc_int_for_mode, at explow.c:56
>
>> 2) Has *anyone* else seen this?
>
>Also spotted on the 3.3 branch, LAST_UPDATED Tue Dec 17 17:49:08
>GMT 2002
>
>> 3) Any suggestions where I should look from here?
>
>Besides running cc1 in gdb and finding out where the offending
>trunc_int_for_mode call comes from? ;-)

Ok, you asked, here's the scoop. try_combine() is called with:

Breakpoint 5, try_combine (i3=0x400bc9a0, i2=0x400bc91c, i1=0x400bc630, 
    new_direct_jump_p=0xbfffef98)
    at /home/pbarada/work/cvs-gnu/uberbaum/gcc/combine.c:1536
(gdb) call debug_rtx(i3)
(insn 22 21 23 0 0x400bc554 (set (cc0)
        (compare (reg/v:SI 37 [ ix ])
            (const_int 838860799 [0x31ffffff]))) 11 {*m68k.md:518} (insn_list 20 (nil))
    (nil))

(gdb) call debug_rtx(i2)
(insn 20 19 21 0 0x400bc554 (set (reg/v:SI 37 [ ix ])
        (and:SI (subreg:SI (reg/v:SF 30 [ x ]) 0)
            (const_int 2147483647 [0x7fffffff]))) 177 {andsi3_internal} (insn_list 3 (nil))
    (nil))

(gdb) call debug_rtx(i1)
(insn 3 267 4 0 (nil) (set (reg/v:SF 30 [ x ])
        (mem/f:SF (plus:SI (reg/f:SI 14 %a6)
                (const_int 8 [0x8])) [2 x+0 S4 A16])) 40 {*m68k.md:1097} (nil)
    (expr_list:REG_EQUIV (mem/f:SF (plus:SI (reg/f:SI 14 %a6)
                (const_int 8 [0x8])) [2 x+0 S4 A16])
        (nil)))

And try_combine puts together:

(gdb) call debug_rtx(x)
(and:SF (mem/f:SF (plus:SI (reg/f:SI 14 %a6)
            (const_int 8 [0x8])) [2 x+0 S4 A16])
    (const_int 2147483647 [0x7fffffff]))

which os passed on to simplify_logical. The callback at the abort is:

(gdb) where
#0  fancy_abort (file=0x8283d80 "/home/pbarada/work/cvs-gnu/uberbaum/gcc/explow.c", 
    line=56, function=0x8283c90 "trunc_int_for_mode")
    at /home/pbarada/work/cvs-gnu/uberbaum/gcc/diagnostic.c:1364
#1  0x080f8d8a in trunc_int_for_mode (c=2147483647, mode=SFmode)
    at /home/pbarada/work/cvs-gnu/uberbaum/gcc/explow.c:56
#2  0x08228546 in simplify_and_const_int (x=0x400ded74, mode=SFmode, varop=0x40021e34, 
    constop=2147483647) at /home/pbarada/work/cvs-gnu/uberbaum/gcc/combine.c:8088
#3  0x082246de in simplify_logical (x=0x400ded74, last=0)
    at /home/pbarada/work/cvs-gnu/uberbaum/gcc/combine.c:5418
#4  0x08223004 in combine_simplify_rtx (x=0x400ded74, op0_mode=VOIDmode, last=0, 
    in_dest=0) at /home/pbarada/work/cvs-gnu/uberbaum/gcc/combine.c:4597
#5  0x08221913 in subst (x=0x400ded74, from=0x4001ffa0, to=0x40021e34, in_dest=0, 
    unique_copy=0) at /home/pbarada/work/cvs-gnu/uberbaum/gcc/combine.c:3575
#6  0x08221804 in subst (x=0x400ded80, from=0x4001ffa0, to=0x40021e34, in_dest=0, 
    unique_copy=0) at /home/pbarada/work/cvs-gnu/uberbaum/gcc/combine.c:3526
#7  0x08221804 in subst (x=0x40021ed0, from=0x4001ffa0, to=0x40021e34, in_dest=0, 
    unique_copy=0) at /home/pbarada/work/cvs-gnu/uberbaum/gcc/combine.c:3526
#8  0x08221804 in subst (x=0x40021edc, from=0x4001ffa0, to=0x40021e34, in_dest=0, 
    unique_copy=0) at /home/pbarada/work/cvs-gnu/uberbaum/gcc/combine.c:3526
#9  0x0821ed1e in try_combine (i3=0x400bc9a0, i2=0x400bc91c, i1=0x400bc630, 
    new_direct_jump_p=0xbfffef98)
    at /home/pbarada/work/cvs-gnu/uberbaum/gcc/combine.c:1987

So trunc_int_mode() is called from simplify_and_const_int() since the
RTL is an AND(with a constant arg), but with SFmode which causes
trunc_int_mode() to barf.

At the start of simplify_logical(), I added:

  /* Can only simplify integer modes  */
  if (!(GET_MODE_CLASS (mode) == MODE_INT || GET_MODE_CLASS (mode) == MODE_PARTIAL_INT))
    return x;

Which forces simplify_logical() to abandon any simplification if the
mode of the expression is not an integer.  With this change I was able
to bootstrap gcc-3.2.1 for i686, and using that bootstrapped compiler,
build a --target-m68k-elf toolchain.  I've also built an m68k-elf
compiler from the uberbaum tree.


-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Re: failuer to build uberbaum --target=m68k-elf

[Peter Barada]

>So trunc_int_mode() is called from simplify_and_const_int() since the
>RTL is an AND(with a constant arg), but with SFmode which causes
>trunc_int_mode() to barf.
>
>At the start of simplify_logical(), I added:
>
>  /* Can only simplify integer modes  */
>  if (!(GET_MODE_CLASS (mode) == MODE_INT || GET_MODE_CLASS (mode) == MODE_PARTIAL_INT))
>    return x;
>
>Which forces simplify_logical() to abandon any simplification if the
>mode of the expression is not an integer.  With this change I was able
>to bootstrap gcc-3.2.1 for i686, and using that bootstrapped compiler,
>build a --target-m68k-elf toolchain.  I've also built an m68k-elf
>compiler from the uberbaum tree.

I updated my uberbaum tree today and it failed to build ef_modf.o (due
to another abort in trunc_int_for_mode), so I've updated my patch to be:

Index: combine.c
===================================================================
RCS file: /cvs/uberbaum/gcc/combine.c,v
retrieving revision 1.335
diff -c -r1.335 combine.c
*** combine.c	1 Feb 2003 18:59:43 -0000	1.335
--- combine.c	6 Feb 2003 05:53:43 -0000
***************
*** 8004,8009 ****
--- 8004,8015 ----
    unsigned HOST_WIDE_INT nonzero;
    int i;
  
+   /* Can only simplify integer modes  */
+   if (!(GET_MODE_CLASS (mode) == MODE_INT || GET_MODE_CLASS (mode) == MODE_PARTIAL_INT))
+     return x;
+ 
    /* Simplify VAROP knowing that we will be only looking at some of the
       bits in it.
  

And have been able to build an i686 compiler which I used to build an
m68k-elf compiler.

Could someone look this over and tell me if I'm barking in the right
direction?  And if so, how can this patch get applied to the gcc sources?

Thanx.

-- 
Peter Barada
peter@baradas.org

Re: failuer to build uberbaum --target=m68k-elf

[Jim Wilson]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

In
	http://gcc.gnu.org/ml/gcc/2003-01/msg01606.html
you mention that combine creates
(and:SF (mem/f:SF (plus:SI (reg/f:SI 14 %a6)
             (const_int 8 [0x8])) [2 x+0 S4 A16])
     (const_int 2147483647 [0x7fffffff]))

The bug here is that we never should have created this rtl because 
AND:SF is not meaningful.  This rtl is created in simplify_comparison 
where it tries to permute AND and SUBREG.  So I believe the correct fix 
is to add a check for an integral mode there, as otherwise this 
optimization is not correct.

I am able to build an uberbaum m68k-elf tree with the following patch, 
except for gdb's lib rda, but that isn't a compiler problem. I will do 
x86 bootstraps tomorrow to verify and then check it into the 3.3 branch 
and the trunk.


[-- Attachment #2: tmp.file --]
[-- Type: text/plain, Size: 1007 bytes --]

2003-02-26  James E Wilson  <wilson@tuliptree.org>

	* combine.c (simplify_comparison): Require integral mode when
	permuting SUBREG with AND.

Index: combine.c
===================================================================
RCS file: /cvs/uberbaum/gcc/combine.c,v
retrieving revision 1.342
diff -p -r1.342 combine.c
*** combine.c	20 Feb 2003 20:56:51 -0000	1.342
--- combine.c	26 Feb 2003 05:58:53 -0000
*************** simplify_comparison (code, pop0, pop1)
*** 11135,11140 ****
--- 11135,11143 ----
  	     represents the low part, permute the SUBREG and the AND and
  	     try again.  */
  	  if (GET_CODE (XEXP (op0, 0)) == SUBREG
+ 	      /* Require an integral mode, to avoid creating something like
+ 		 (AND:SF ...).  */
+ 	      && SCALAR_INT_MODE_P (GET_MODE (SUBREG_REG (XEXP (op0, 0))))
  	      /* It is unsafe to commute the AND into the SUBREG if the SUBREG
  		 is paradoxical and WORD_REGISTER_OPERATIONS is not defined.
  		 As originally written the upper bits have a defined value

Re: failuer to build uberbaum --target=m68k-elf

[Joel Sherrill]

Is this PR8343?

Jim Wilson wrote:
> 
> In
>         http://gcc.gnu.org/ml/gcc/2003-01/msg01606.html
> you mention that combine creates
> (and:SF (mem/f:SF (plus:SI (reg/f:SI 14 %a6)
>              (const_int 8 [0x8])) [2 x+0 S4 A16])
>      (const_int 2147483647 [0x7fffffff]))
> 
> The bug here is that we never should have created this rtl because
> AND:SF is not meaningful.  This rtl is created in simplify_comparison
> where it tries to permute AND and SUBREG.  So I believe the correct fix
> is to add a check for an integral mode there, as otherwise this
> optimization is not correct.
> 
> I am able to build an uberbaum m68k-elf tree with the following patch,
> except for gdb's lib rda, but that isn't a compiler problem. I will do
> x86 bootstraps tomorrow to verify and then check it into the 3.3 branch
> and the trunk.
> 
>   ------------------------------------------------------------------------
> 2003-02-26  James E Wilson  <wilson@tuliptree.org>
> 
>         * combine.c (simplify_comparison): Require integral mode when
>         permuting SUBREG with AND.
> 
> Index: combine.c
> ===================================================================
> RCS file: /cvs/uberbaum/gcc/combine.c,v
> retrieving revision 1.342
> diff -p -r1.342 combine.c
> *** combine.c   20 Feb 2003 20:56:51 -0000      1.342
> --- combine.c   26 Feb 2003 05:58:53 -0000
> *************** simplify_comparison (code, pop0, pop1)
> *** 11135,11140 ****
> --- 11135,11143 ----
>              represents the low part, permute the SUBREG and the AND and
>              try again.  */
>           if (GET_CODE (XEXP (op0, 0)) == SUBREG
> +             /* Require an integral mode, to avoid creating something like
> +                (AND:SF ...).  */
> +             && SCALAR_INT_MODE_P (GET_MODE (SUBREG_REG (XEXP (op0, 0))))
>               /* It is unsafe to commute the AND into the SUBREG if the SUBREG
>                  is paradoxical and WORD_REGISTER_OPERATIONS is not defined.
>                  As originally written the upper bits have a defined value

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

Re: failuer to build uberbaum --target=m68k-elf

[Jim Wilson]

On Wed, 2003-02-26 at 09:27, Joel Sherrill wrote:
> Is this PR8343?

No.  PR 8343 was already fixed by a patch from Jan Hubicka, and the
patch is already in both trunk and the gcc-3.3 branch.  He added it to
the branch yesterday.  I see the PR refers to gcc-3.2.  Do you need the
patch added to the gcc-3.2 branch?  If someone tests the patch with the
gcc-3.2 branch I am willing to do that.  I don't have any convenient way
to do that at the moment; I don't even have a copy checked out.

I don't know if there is a PR for the combine problem.

Jim

Re: failuer to build uberbaum --target=m68k-elf

[Joel Sherrill]

Jim Wilson wrote:
> 
> On Wed, 2003-02-26 at 09:27, Joel Sherrill wrote:
> > Is this PR8343?
> 
> No.  PR 8343 was already fixed by a patch from Jan Hubicka, and the
> patch is already in both trunk and the gcc-3.3 branch.  He added it to
> the branch yesterday.  I see the PR refers to gcc-3.2.  Do you need the
> patch added to the gcc-3.2 branch?  If someone tests the patch with the
> gcc-3.2 branch I am willing to do that.  I don't have any convenient way
> to do that at the moment; I don't even have a copy checked out.

I can test it against 3.2 if you check it in. Is it sufficient to say
that
the compiler does not ICE?

Doing a search on m68 I see that there are a handful of PRs citing
places
close together for ICEs.  Maybe this fixes more than 1 PR.  Could
someone
check that it didn't also fix:

  PR9389 - [3.2/3.3 regression] [m68k] ICE in
instantiate_virtual_regs_1, at function.c:4134
  PR9248 - [m68k] compiling C++ file from ACE causes ICE on m68k-rtems
target
  
Also in looking at m68k PRs, I see that PR3794 no longer applies since
it
is against 3.0 and m68k toolsets could be built on the 3.2 branch.  This
is a problem when building newlib.  

Ditto for PR4634 and PR1795.  They have to be fixed in newer versions
since
m68k-elf, m68k-coff, m68k-rtems, and (I have to believe) m68k-linux have
been
built on 3.2.

There are others but I can't tell about them.  We might be able to close
a bunch.

> I don't know if there is a PR for the combine problem.

I think 9255 may be it since that is the most recent m68k one I have
filed
and I am fairly certain Peter sent me the patch in response to queries
on the list about failures building 3.3 without it.

> Jim

--joel

Re: failuer to build uberbaum --target=m68k-elf

[Peter Barada]

>> I don't know if there is a PR for the combine problem.
>
>I think 9255 may be it since that is the most recent m68k one I have
>filed and I am fairly certain Peter sent me the patch in response to
>queries on the list about failures building 3.3 without it.

Joel,

Indeed Jim's patch is a *much* better version of the brute-force patch
that I sent you.  PR 9255 is the bug associated with this patch.
Since the errant RTL wasn't put into the PR, it made it much harder to
find. 

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Re: failuer to build uberbaum --target=m68k-elf

[Jim Wilson]

PR 8343
I added the patch to the gcc-3.2 branch and closed this PR.  You may
want to retest the gcc-3.2 branch.

PR 9255
I added the patch to the trunk and gcc-3.3 branch and closed this PR. 
You may want to retest the gcc-3.3 branch.

You mentioned 5 other PR numbers.  I will try looking at them.  PR 9389
looks like a duplicate of 9255.  PR 9248 looks like a different
problem.  I haven't looked at the others yet.

Jim

Re: failuer to build uberbaum --target=m68k-elf

[Joel Sherrill]

Jim Wilson wrote:
> 
> PR 8343
> I added the patch to the gcc-3.2 branch and closed this PR.  You may
> want to retest the gcc-3.2 branch.
> 
> PR 9255
> I added the patch to the trunk and gcc-3.3 branch and closed this PR.
> You may want to retest the gcc-3.3 branch.
> 
> You mentioned 5 other PR numbers.  I will try looking at them.  PR 9389
> looks like a duplicate of 9255.  PR 9248 looks like a different
> problem.  I haven't looked at the others yet.

Thanks for closing these two and looking at the others.  The older ones
just look like they got fixed and no one noticed.  m68k-elf has been in
a buildable shape for a while since 3.0.

I am updating my 3.2 branch now.

> Jim

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