m68k bootstrapping broken

m68k bootstrapping broken

[Richard Zidlicky]

Hello,

I am testing gcc-3.4-20031210. Bootstrapping fails with
this problems:

stage1/xgcc -Bstage1/ -B/usr/m68k-rz-linux/bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition -Werror    -DHAVE_CONFIG_H    -I. -I. -I../../gcc-3.4-20031210/gcc -I../../gcc-3.4-20031210/gcc/. -I../../gcc-3.4-20031210/gcc/../include  \
        ../../gcc-3.4-20031210/gcc/config/m68k/m68k.c -o m68k.o
../../gcc-3.4-20031210/gcc/config/m68k/m68k.c: In function `output_andsi3':

../../gcc-3.4-20031210/gcc/config/m68k/m68k.c:3285: warning: comparison between 
signed and unsigned
make[2]: *** [m68k.o] Error 1

....
....
....

/sources/rz-rpm/BUILD/build-gcc-3.4.0/gcc/xgcc -B/sources/rz-rpm/BUILD/build-gcc-3.4.0/gcc/ -B/usr/m68k-rz-linux/bin/ -B/usr/m68k-rz-linux/lib/ -isystem /usr/m68k-rz-linux/include -isystem /usr/m68k-rz-linux/sys-include -O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include -O3 -fomit-frame-pointer -m68020-60   -O2 -Dmc68060 -D__mc68060__ -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I -I../../gcc-3.4-20031210/gcc -I../../gcc-3.4-20031210/gcc/ -I../../gcc-3.4-20031210/gcc/../include   -DL_lshrdi3 -c ../../gcc-3.4-20031210/gcc/libgcc2.c -o libgcc/./_lshrdi3.o

../../gcc-3.4-20031210/gcc/libgcc2.c: In function `__lshrdi3':
../../gcc-3.4-20031210/gcc/libgcc2.c:361: error: unrecognizable insn:
(insn 35 34 36 3 ../../gcc-3.4-20031210/gcc/libgcc2.c:350 (set (reg:SI 39)
        (lshiftrt:SI (subreg:SI (reg/v:DI 35 [ uu ]) 0)
            (reg:SI 38))) -1 (insn_list 34 (nil))
    (expr_list:REG_DEAD (reg/v:DI 35 [ uu ])
        (expr_list:REG_DEAD (reg:SI 38)
            (expr_list:REG_EQUAL (lshiftrt:SI (subreg:SI (reg/v:DI 35 [ uu ]) 0)
                    (reg:SI 38))
                (nil)))))
../../gcc-3.4-20031210/gcc/libgcc2.c:361: internal compiler error: in extract_insn, at recog.c:2061

When I compile libgcc with the same flags with a crosscompiler this
doesnt happen so it appears the compiler has miscompiled itself
somewhere else.. anyone else seen this?

I tried bootstrapping from gcc2723 and a 386 hosted gcc-3.2 crosscompiler,
same result both times.

The crosscompiler so far works pretty well btw, working 2.4 & 2.6
kernels and some 3.2 problems fixed.

Richard

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:
> Hello,
> 
> I am testing gcc-3.4-20031210. Bootstrapping fails with
> this problems:
> 
> stage1/xgcc -Bstage1/ -B/usr/m68k-rz-linux/bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition -Werror    -DHAVE_CONFIG_H    -I. -I. -I../../gcc-3.4-20031210/gcc -I../../gcc-3.4-20031210/gcc/. -I../../gcc-3.4-20031210/gcc/../include  \
>         ../../gcc-3.4-20031210/gcc/config/m68k/m68k.c -o m68k.o
> ../../gcc-3.4-20031210/gcc/config/m68k/m68k.c: In function `output_andsi3':
> 
> ../../gcc-3.4-20031210/gcc/config/m68k/m68k.c:3285: warning: comparison between 
> signed and unsigned
> make[2]: *** [m68k.o] Error 1

Are you building with --enable-werror ?  This is a long-standing warning,
I'll fix that.

> /sources/rz-rpm/BUILD/build-gcc-3.4.0/gcc/xgcc -B/sources/rz-rpm/BUILD/build-gcc-3.4.0/gcc/ -B/usr/m68k-rz-linux/bin/ -B/usr/m68k-rz-linux/lib/ -isystem /usr/m68k-rz-linux/include -isystem /usr/m68k-rz-linux/sys-include -O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ./include -O3 -fomit-frame-pointer -m68020-60   -O2 -Dmc68060 -D__mc68060__ -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I -I../../gcc-3.4-20031210/gcc -I../../gcc-3.4-20031210/gcc/ -I../../gcc-3.4-20031210/gcc/../include   -DL_lshrdi3 -c ../../gcc-3.4-20031210/gcc/libgcc2.c -o libgcc/./_lshrdi3.o
> 
> ../../gcc-3.4-20031210/gcc/libgcc2.c: In function `__lshrdi3':
> ../../gcc-3.4-20031210/gcc/libgcc2.c:361: error: unrecognizable insn:
> (insn 35 34 36 3 ../../gcc-3.4-20031210/gcc/libgcc2.c:350 (set (reg:SI 39)
>         (lshiftrt:SI (subreg:SI (reg/v:DI 35 [ uu ]) 0)
>             (reg:SI 38))) -1 (insn_list 34 (nil))
>     (expr_list:REG_DEAD (reg/v:DI 35 [ uu ])
>         (expr_list:REG_DEAD (reg:SI 38)
>             (expr_list:REG_EQUAL (lshiftrt:SI (subreg:SI (reg/v:DI 35 [ uu ]) 0)
>                     (reg:SI 38))
>                 (nil)))))
> ../../gcc-3.4-20031210/gcc/libgcc2.c:361: internal compiler error: in extract_insn, at recog.c:2061
> 
> When I compile libgcc with the same flags with a crosscompiler this
> doesnt happen so it appears the compiler has miscompiled itself
> somewhere else.. anyone else seen this?

Never in m68k-*-uclinux nor m68k-*-elf.  Neither uses -m68020-60, but
I still can't reproduce the problem compiling the same code with m68k-uclinux-gcc:

% m68k-uclinux-gcc -O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem ../../combined-HEAD/gcc -isystem ./include -O3 -fomit-frame-pointer -m68020-60   -O2 -Dmc68060 -D__mc68060__ -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I -I../../combined-HEAD/gcc -I../../combined-HEAD/gcc/../include   -DL_lshrdi3 -c ../../combined-HEAD/gcc/libgcc2.c -o foo.o
% m68k-uclinux-objdump -d foo.o

foo.o:     file format elf32-m68k

Disassembly of section .text:

00000000 <__lshrdi3>:
   0:   48e7 3e00       moveml %d2-%d6,%sp@-
   4:   41ef 0018       lea %sp@(24),%a0
   8:   2410            movel %a0@,%d2
   a:   2628 0004       movel %a0@(4),%d3
   e:   2828 0008       movel %a0@(8),%d4
  12:   2002            movel %d2,%d0
  14:   2203            movel %d3,%d1
  16:   4a84            tstl %d4
  18:   672a            beqs 44 <__lshrdi3+0x44>
  1a:   7020            moveq #32,%d0
  1c:   9084            subl %d4,%d0
  1e:   4a80            tstl %d0
  20:   6f16            bles 38 <__lshrdi3+0x38>
  22:   2202            movel %d2,%d1
  24:   e1a9            lsll %d0,%d1
  26:   2a02            movel %d2,%d5
  28:   e8ad            lsrl %d4,%d5
  2a:   2003            movel %d3,%d0
  2c:   e8a8            lsrl %d4,%d0
  2e:   2c00            movel %d0,%d6
  30:   8c81            orl %d1,%d6
  32:   2005            movel %d5,%d0
  34:   2206            movel %d6,%d1
  36:   600c            bras 44 <__lshrdi3+0x44>
  38:   4285            clrl %d5
  3a:   4480            negl %d0
  3c:   2c02            movel %d2,%d6
  3e:   e0ae            lsrl %d0,%d6
  40:   2005            movel %d5,%d0
  42:   2206            movel %d6,%d1
  44:   4cdf 007c       moveml %sp@+,%d2-%d6
  48:   4e75            rts


Do you have any local patches that might be triggering this ICE?
You may also want to retry with a more recent CVS snapshot,
just in case.


> The crosscompiler so far works pretty well btw, working 2.4 & 2.6
> kernels and some 3.2 problems fixed.

That's good news.  As you might have noticed, the m68k backend has
been tortured quite a lot lately :-)

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Mon, Jan 05, 2004 at 05:06:11AM +0100, Bernardo Innocenti wrote:
> Richard Zidlicky wrote:
> >Hello,
> >
> >I am testing gcc-3.4-20031210. Bootstrapping fails with
> >this problems:
> >
> >stage1/xgcc -Bstage1/ -B/usr/m68k-rz-linux/bin/ -c   -g -O2 -DIN_GCC   -W 
> >-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic 
> >-Wno-long-long -Wold-style-definition -Werror    -DHAVE_CONFIG_H    -I. 
> >-I. -I../../gcc-3.4-20031210/gcc -I../../gcc-3.4-20031210/gcc/. 
> >-I../../gcc-3.4-20031210/gcc/../include  \
> >        ../../gcc-3.4-20031210/gcc/config/m68k/m68k.c -o m68k.o
> >../../gcc-3.4-20031210/gcc/config/m68k/m68k.c: In function `output_andsi3':
> >
> >../../gcc-3.4-20031210/gcc/config/m68k/m68k.c:3285: warning: comparison 
> >between signed and unsigned
> >make[2]: *** [m68k.o] Error 1
> 
> Are you building with --enable-werror ?  

yes, thats what "make bootstrap" did for me. I had to override
the Makefile to proceed to the next error.

> This is a long-standing warning,
> I'll fix that.

thanks.


> >/sources/rz-rpm/BUILD/build-gcc-3.4.0/gcc/xgcc 
> >-B/sources/rz-rpm/BUILD/build-gcc-3.4.0/gcc/ -B/usr/m68k-rz-linux/bin/ 
> >-B/usr/m68k-rz-linux/lib/ -isystem /usr/m68k-rz-linux/include -isystem 
> >/usr/m68k-rz-linux/sys-include -O2  -DIN_GCC    -W -Wall -Wwrite-strings 
> >-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem 
> >./include -O3 -fomit-frame-pointer -m68020-60   -O2 -Dmc68060 
> >-D__mc68060__ -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED 
> >-I. -I -I../../gcc-3.4-20031210/gcc -I../../gcc-3.4-20031210/gcc/ 
> >-I../../gcc-3.4-20031210/gcc/../include   -DL_lshrdi3 -c 
> >../../gcc-3.4-20031210/gcc/libgcc2.c -o libgcc/./_lshrdi3.o
> >
> >../../gcc-3.4-20031210/gcc/libgcc2.c: In function `__lshrdi3':
> >../../gcc-3.4-20031210/gcc/libgcc2.c:361: error: unrecognizable insn:
> >(insn 35 34 36 3 ../../gcc-3.4-20031210/gcc/libgcc2.c:350 (set (reg:SI 39)
> >        (lshiftrt:SI (subreg:SI (reg/v:DI 35 [ uu ]) 0)
> >            (reg:SI 38))) -1 (insn_list 34 (nil))
> >    (expr_list:REG_DEAD (reg/v:DI 35 [ uu ])
> >        (expr_list:REG_DEAD (reg:SI 38)
> >            (expr_list:REG_EQUAL (lshiftrt:SI (subreg:SI (reg/v:DI 35 [ uu 
> >            ]) 0)
> >                    (reg:SI 38))
> >                (nil)))))
> >../../gcc-3.4-20031210/gcc/libgcc2.c:361: internal compiler error: in 
> >extract_insn, at recog.c:2061
> >
> >When I compile libgcc with the same flags with a crosscompiler this
> >doesnt happen so it appears the compiler has miscompiled itself
> >somewhere else.. anyone else seen this?
> 
> Never in m68k-*-uclinux nor m68k-*-elf.  Neither uses -m68020-60, but
> I still can't reproduce the problem compiling the same code with 
> m68k-uclinux-gcc:
> 
> % m68k-uclinux-gcc -O2  -DIN_GCC    -W -Wall -Wwrite-strings 
....
....

did you ever bootstrap the compiler on uclinux? It does not happen
here with a crosscompiler here either.. in fact it built libgcc
and libstdc without problems.
It does happen with stage1 bootstrapped gcc and with a gcc that was
itself cross compiled for m68k-linux.

Does gcc-3.4 use any new binutils features aggressively?

> Do you have any local patches that might be triggering this ICE?

I have the "--with-cpu" and global register variables patches,
both very low on the list of suspects.

> You may also want to retry with a more recent CVS snapshot,
> just in case.
> 
> 
> >The crosscompiler so far works pretty well btw, working 2.4 & 2.6
> >kernels and some 3.2 problems fixed.
> 
> That's good news.  As you might have noticed, the m68k backend has
> been tortured quite a lot lately :-)

yes, quite a facelift.

Richard

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:

>>>../../gcc-3.4-20031210/gcc/config/m68k/m68k.c:3285: warning: comparison 
>>>between signed and unsigned
>>>make[2]: *** [m68k.o] Error 1
>>
>>Are you building with --enable-werror ?  
> 
> yes, thats what "make bootstrap" did for me. I had to override
> the Makefile to proceed to the next error.

Beware that recent CVS snapshots throw quite a few warnings due to
aggressive optimizations employing a GCC extension for non-integer
bitfields.

>>This is a long-standing warning,
>>I'll fix that.
> 
> thanks.

It's now fixed in CVS.  I've also noticed a few warnings in m68k.md,
but I've not yet investigated them.


>>% m68k-uclinux-gcc -O2  -DIN_GCC    -W -Wall -Wwrite-strings 
> 
> ....
>
> did you ever bootstrap the compiler on uclinux? It does not happen
> here with a crosscompiler here either.. in fact it built libgcc
> and libstdc without problems.

I couldn't ever build GCC *on* uClinux: my only ColdFire board has
just 4MB of ram and 2MB of flash ;-)


> It does happen with stage1 bootstrapped gcc and with a gcc that was
> itself cross compiled for m68k-linux.
> 
> Does gcc-3.4 use any new binutils features aggressively?

Not that I know of.  AFAIK, any GCC version should work even with
non GNU linkers.  All the advanced linker stuff can be emulated
by collect2.

> I have the "--with-cpu" and global register variables patches,
> both very low on the list of suspects.

Hmmm... I'd suspect anything that changes m68k.md or the target
hooks in m68k.h.  Perhaps linux.h overrides something that
interacts with register allocation?

>>That's good news.  As you might have noticed, the m68k backend has
>>been tortured quite a lot lately :-)
> 
> yes, quite a facelift.

I'm anxiously waiting for the 3.4 branch to remove even more cruft
from the m68k backend.  All targets using the SGS assembler have
been deprecated and we can now get rid of it :-)

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Tue, Jan 06, 2004 at 02:07:10AM +0100, Bernardo Innocenti wrote:

> 
> I couldn't ever build GCC *on* uClinux: my only ColdFire board has
> just 4MB of ram and 2MB of flash ;-)

might still be enough to try a crosscompiled cc1 natively?

> >I have the "--with-cpu" and global register variables patches,
> >both very low on the list of suspects.
> 
> Hmmm... I'd suspect anything that changes m68k.md or the target
> hooks in m68k.h.  Perhaps linux.h overrides something that
> interacts with register allocation?

Linux has different register usage for function call returns
but only scratch registers are involved. Other than that there
is nothing close to suspicious.

Richard

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:

>>I couldn't ever build GCC *on* uClinux: my only ColdFire board has
>>just 4MB of ram and 2MB of flash ;-)
> 
> might still be enough to try a crosscompiled cc1 natively?

Not at all: after loading the kernel and running a shell, free
memory drops to 2.5MB, which is *far* less than the mere size
of cc1's text segment, to say nothing about the run-time footprint :-)

I'd like to experiment with a ColdFire 5200 simulator to see if
I can get it to work with remote dejagnu.  It's slow like hell though.


btw, since you're one of the few who can test GCC 3.4 on m68k-linux,
would you mind to review some of these PRs?  I've recently checked
some of them to see if I could help, but (un)fortunately none of
them affect my targets:

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=m68k&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED


>>Hmmm... I'd suspect anything that changes m68k.md or the target
>>hooks in m68k.h.  Perhaps linux.h overrides something that
>>interacts with register allocation?
> 
> Linux has different register usage for function call returns
> but only scratch registers are involved. Other than that there
> is nothing close to suspicious.

Then all m68k targets should be seing the same ICE, which is not
the case.

It's way possible that the real problem might be somewhere in the
middle-end, but it's most probably being triggered by the m68k-linux
specific configuration.

Changes in register allocation are likely candidates because they
make code generation take different paths.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Peter Barada]

>>>I couldn't ever build GCC *on* uClinux: my only ColdFire board has
>>>just 4MB of ram and 2MB of flash ;-)
>> 
>> might still be enough to try a crosscompiled cc1 natively?
>
>Not at all: after loading the kernel and running a shell, free
>memory drops to 2.5MB, which is *far* less than the mere size
>of cc1's text segment, to say nothing about the run-time footprint :-)
>
>I'd like to experiment with a ColdFire 5200 simulator to see if
>I can get it to work with remote dejagnu.  It's slow like hell though.

Try the one at <http://www.lightbox.org/coldfire/index.php>  it
*boots* uClinux!

-- 
Peter Barada
peter@the-baradas.com

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Peter Barada wrote:
>>>>I couldn't ever build GCC *on* uClinux: my only ColdFire board has
>>>>just 4MB of ram and 2MB of flash ;-)
>>>
>>>might still be enough to try a crosscompiled cc1 natively?
>>
>>Not at all: after loading the kernel and running a shell, free
>>memory drops to 2.5MB, which is *far* less than the mere size
>>of cc1's text segment, to say nothing about the run-time footprint :-)
>>
>>I'd like to experiment with a ColdFire 5200 simulator to see if
>>I can get it to work with remote dejagnu.  It's slow like hell though.
> 
> 
> Try the one at <http://www.lightbox.org/coldfire/index.php>  it
> *boots* uClinux!

Yeah, that's the one I was referring to.  Being able to run uClinux
in the emulator is amazing, but it's much slower than the real thing.

A nice project would be porting it to the GDB simulator infrastructure,
but I realized it would be a lot of work.  Besides, it only emulates a
5200, which renders it almost useless for automated GCC regression
testing.

Another possibility could be porting the UAE emulation core instead.
It doesn't handle ColdFire processors, but adding the CF instruction
set shouldn't be too much work.  The real issue is emulating all the
ColdFire peripherals :-(

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Peter Barada]

>Yeah, that's the one I was referring to.  Being able to run uClinux
>in the emulator is amazing, but it's much slower than the real thing.

It's not that slow when you run it on a honking x86 box!

>A nice project would be porting it to the GDB simulator infrastructure,
>but I realized it would be a lot of work.  Besides, it only emulates a
>5200, which renders it almost useless for automated GCC regression
>testing.

It won't be that hard to make it work for a 5206e/5272/528x/5249, at
least from the core perspective(just need to add the div/mod
instructions and the extra v2 insn for the 528x).  Adding in the v4
instructions shouldn't be too hard either.

I've looked at porting it over to GDB, and came to the same conclusion
about the scale of work required. It's probably easier to start over
using the GDB simulator framework.

Anyone game to help on that?

>Another possibility could be porting the UAE emulation core instead.
>It doesn't handle ColdFire processors, but adding the CF instruction
>set shouldn't be too much work.  The real issue is emulating all the
>ColdFire peripherals :-(

Do we really need all the peripherals?  Just the serial ports should do.
Besides, the UAE doesn't handle the GDB simulator framework either.

-- 
Peter Barada
peter@the-baradas.com

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Peter Barada wrote:
>>Yeah, that's the one I was referring to.  Being able to run uClinux
>>in the emulator is amazing, but it's much slower than the real thing.
> 
> It's not that slow when you run it on a honking x86 box!

I've not done any real benchmarking, but the feeling is an order of
magnitude slower than the 5272EVM on my Athlon 2200.  Instead, UAE
runs 3x faster than a 50MHz 68060 even with JIT turned off.


>>A nice project would be porting it to the GDB simulator infrastructure,
>>but I realized it would be a lot of work.  Besides, it only emulates a
>>5200, which renders it almost useless for automated GCC regression
>>testing.
> 
> It won't be that hard to make it work for a 5206e/5272/528x/5249, at
> least from the core perspective(just need to add the div/mod
> instructions and the extra v2 insn for the 528x).  Adding in the v4
> instructions shouldn't be too hard either.

Yes, but I think the emulator also lacks the required infrastructure
to select multiple CPUs at run-time.

And we also need to emulate the 680x0 family in order to run the
testsuite properly :-(


> I've looked at porting it over to GDB, and came to the same conclusion
> about the scale of work required. It's probably easier to start over
> using the GDB simulator framework.

My thought too, but the emulator core could still be ripped off
the ColdFire emulator or UAE instead of starting over.

> Anyone game to help on that?

I'd like too, but I'm afraid I lack both time and knowledge.
If you're going to write the core code, I could contribute testing,
bug-fixing and small enhancements.  I also volunteer doing the work
of submitting patches for integration into the sourceware repository.


>>Another possibility could be porting the UAE emulation core instead.
>>It doesn't handle ColdFire processors, but adding the CF instruction
>>set shouldn't be too much work.  The real issue is emulating all the
>>ColdFire peripherals :-(
> 
> Do we really need all the peripherals?  Just the serial ports should do.
> Besides, the UAE doesn't handle the GDB simulator framework either.

Serial ports suffice to test m68k-elf.  If we ever want to support
m68k-uclinux, we'll have to provide everything that the uClinux kernel
expects, like the ColdFire emulator does.  If we even want to run
m68k-linux, we'll also have to emulate the MMU and perhaps even caches.

The Sky Eye emulator does that for ARM processors, but it's an
ambitious project with lots of resources.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Peter Barada]

>> It won't be that hard to make it work for a 5206e/5272/528x/5249, at
>> least from the core perspective(just need to add the div/mod
>> instructions and the extra v2 insn for the 528x).  Adding in the v4
>> instructions shouldn't be too hard either.
>
>Yes, but I think the emulator also lacks the required infrastructure
>to select multiple CPUs at run-time.

Yes, it does.  Its all trade;  do you add ColdFire bits to UAE and then
go through the hassle of getting uClinux to boot, or do you add the
other bits to the emulator at lightbox.  I understand that performance
of the emulator at lightbox can be improved, and I see ways to speed
it up, or do we take all ot the above and produce one frm scratch that
has the benifit of being usable as a simulator by GDB?

I'm happy to go in any direction, I just want to know its the right
one :-)  As a side note, I've already started on building a UAE style
instruction decoder for ColdFire, and have a decoder that produces a
full table for V4. It should be pretty trivial to have it genreate the
table at startup based on which CPU model you want...

-- 
Peter Barada
peter@the-baradas.com

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Peter Barada wrote:

>>>It won't be that hard to make it work for a 5206e/5272/528x/5249, at
>>>least from the core perspective(just need to add the div/mod
>>>instructions and the extra v2 insn for the 528x).  Adding in the v4
>>>instructions shouldn't be too hard either.
>>
>>Yes, but I think the emulator also lacks the required infrastructure
>>to select multiple CPUs at run-time.
> 
> Yes, it does.  Its all trade;  do you add ColdFire bits to UAE and then
> go through the hassle of getting uClinux to boot, or do you add the
> other bits to the emulator at lightbox.  I understand that performance
> of the emulator at lightbox can be improved, and I see ways to speed
> it up, or do we take all ot the above and produce one frm scratch that
> has the benifit of being usable as a simulator by GDB?

Do we really need to start from scratch?  Can't we massage existing
code until it fits into GDB's simulator infrastructure?

Even though in the end you'll have rewritten every single line of the
emulator, usually the time you save in design and debug are worth it.

I tend to avoid starting projects from scratch when there's even the
smallest chance to use existing code, as ugly, buggy or limited as it
may be :-)

By the way, all the projects we're talking about GPLed, so there are
no legal issues.


> I'm happy to go in any direction, I just want to know its the right
> one :-)  As a side note, I've already started on building a UAE style
> instruction decoder for ColdFire, and have a decoder that produces a
> full table for V4. It should be pretty trivial to have it genreate the
> table at startup based on which CPU model you want...

That's great news!  UAE's cpugen also has some questionable x86
optimizations done by post-processing GCC's assembly output.  Of course
it breaks on every new GCC release, so I don't think I'd want to maintain
such a thing ;-)


Another thing.  I'm playing with libffi to see if I can get it to work
on plain 68000.   Do you know a simple instruction sequence to replace
this bit-field operation?

   bfins   %d0,(%a1){#0,%d2}


I was thinking of something like this (in pseudo-C):

   mask = (1 << (d2 & 0x1f)) - 1;
   *a1 = (*a2 & ~mask) | (d0 & mask);

This should work like bfins for any value of d2,
but the code as produced by GCC is quite longwinded:

        moveq   #31,%d1
        and.l   %d1,%d0
        move.b  #1,%d1
        lsl.l   %d0,%d1
        subq.l  #1,%d1
        move.l  %d1,%d0
        not.l   %d0
        and.l   (%a1),%d0
        and.l   %d1,%d2
        or.l    %d2,%d0
        move.l  %d0,(%a1)

Is there a more efficient way?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Peter Barada]

>>>>It won't be that hard to make it work for a 5206e/5272/528x/5249, at
>>>>least from the core perspective(just need to add the div/mod
>>>>instructions and the extra v2 insn for the 528x).  Adding in the v4
>>>>instructions shouldn't be too hard either.
>>>
>>>Yes, but I think the emulator also lacks the required infrastructure
>>>to select multiple CPUs at run-time.
>> 
>> Yes, it does.  Its all trade;  do you add ColdFire bits to UAE and then
>> go through the hassle of getting uClinux to boot, or do you add the
>> other bits to the emulator at lightbox.  I understand that performance
>> of the emulator at lightbox can be improved, and I see ways to speed
>> it up, or do we take all ot the above and produce one frm scratch that
>> has the benifit of being usable as a simulator by GDB?
>
>Do we really need to start from scratch?  Can't we massage existing
>code until it fits into GDB's simulator infrastructure?
>
>Even though in the end you'll have rewritten every single line of the
>emulator, usually the time you save in design and debug are worth it.
>
>I tend to avoid starting projects from scratch when there's even the
>smallest chance to use existing code, as ugly, buggy or limited as it
>may be :-)

If you're tryong to make a McLaren F1 car, you surely don't want to
start with a Model T.  It all depends on what you're starting with and
what you're trying to make.  I do agree with ripping off as much so
the reinvention of the wheel is limited, but sometimes starting with a
clean slate is easier.

>By the way, all the projects we're talking about GPLed, so there are
>no legal issues.

Yes, there is that. That's why I've been looking at both(in my copious
spare time of course).

>> I'm happy to go in any direction, I just want to know its the right
>> one :-)  As a side note, I've already started on building a UAE style
>> instruction decoder for ColdFire, and have a decoder that produces a
>> full table for V4. It should be pretty trivial to have it genreate the
>> table at startup based on which CPU model you want...
>
>That's great news!  UAE's cpugen also has some questionable x86
>optimizations done by post-processing GCC's assembly output.  Of course
>it breaks on every new GCC release, so I don't think I'd want to maintain
>such a thing ;-)

I'll look at having it encode instructions with a model selector in
the first filed so we can have it produce different decode selectors.

>Another thing.  I'm playing with libffi to see if I can get it to work
>on plain 68000.   Do you know a simple instruction sequence to replace
>this bit-field operation?
>
>   bfins   %d0,(%a1){#0,%d2}
>
>
>I was thinking of something like this (in pseudo-C):
>
>   mask = (1 << (d2 & 0x1f)) - 1;
>   *a1 = (*a2 & ~mask) | (d0 & mask);
>
>This should work like bfins for any value of d2,
>but the code as produced by GCC is quite longwinded:
>
>        moveq   #31,%d1
>        and.l   %d1,%d0
>        move.b  #1,%d1
>        lsl.l   %d0,%d1
>        subq.l  #1,%d1
>        move.l  %d1,%d0
>        not.l   %d0
>        and.l   (%a1),%d0
>        and.l   %d1,%d2
>        or.l    %d2,%d0
>        move.l  %d0,(%a1)
>
>Is there a more efficient way?

Let me think for a bit.  Perhaps I'll code it up for superopt to
crunch over for a while...

-- 
Peter Barada
peter@the-baradas.com

Re: m68k bootstrapping broken

[Andreas Schwab]

Bernardo Innocenti <bernie@develer.com> writes:

> Another thing.  I'm playing with libffi to see if I can get it to work
> on plain 68000.   Do you know a simple instruction sequence to replace
> this bit-field operation?
>
>    bfins   %d0,(%a1){#0,%d2}
>
>
> I was thinking of something like this (in pseudo-C):
>
>    mask = (1 << (d2 & 0x1f)) - 1;
>    *a1 = (*a2 & ~mask) | (d0 & mask);

The mask is wrong. The bitfield insns number the bits from MSB to LSB, not
the other way round, as the single bit insns do.  Also, a width of 0 is
replaced by 32.

     shift = 32 - (d2 & 0x1f);
     if (shift == 32) mask = 0, shift = 0;
     else mask = (1 << shift) - 1;
     *a1 = (*a2 & mask) | (d0 << shift);

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Andreas Schwab]

Andreas Schwab <schwab@suse.de> writes:

> Bernardo Innocenti <bernie@develer.com> writes:
>
>> Another thing.  I'm playing with libffi to see if I can get it to work
>> on plain 68000.   Do you know a simple instruction sequence to replace
>> this bit-field operation?
>>
>>    bfins   %d0,(%a1){#0,%d2}
>>
>>
>> I was thinking of something like this (in pseudo-C):
>>
>>    mask = (1 << (d2 & 0x1f)) - 1;
>>    *a1 = (*a2 & ~mask) | (d0 & mask);
>
> The mask is wrong. The bitfield insns number the bits from MSB to LSB, not
> the other way round, as the single bit insns do.  Also, a width of 0 is
> replaced by 32.
>
>      shift = 32 - (d2 & 0x1f);
>      if (shift == 32) mask = 0, shift = 0;
>      else mask = (1 << shift) - 1;
>      *a1 = (*a2 & mask) | (d0 << shift);

Here is a better version:

      shift = d2 & 0x1f;
      if (shift == 0) mask = 0, shift = 32;
      else mask = 0xFFFFFFFF >> shift;
      *a1 = (*a2 & mask) | (d0 << (32 - shift));

(If the offset is nonzero it gets even more complicated.)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Andreas Schwab wrote:
> Bernardo Innocenti <bernie@develer.com> writes:
> 
> 
>>Another thing.  I'm playing with libffi to see if I can get it to work
>>on plain 68000.   Do you know a simple instruction sequence to replace
>>this bit-field operation?
>>
>>   bfins   %d0,(%a1){#0,%d2}
>>
>>
>>I was thinking of something like this (in pseudo-C):
>>
>>   mask = (1 << (d2 & 0x1f)) - 1;
>>   *a1 = (*a2 & ~mask) | (d0 & mask);
> 
> 
> The mask is wrong. The bitfield insns number the bits from MSB to LSB, not
> the other way round, as the single bit insns do.  Also, a width of 0 is
> replaced by 32.
  ^^^^^^^^^^^^^^

This does only happen for immediate modes, to fit the valid range within the
available 5 bits.  When using a data register, the width and offest are just
wrapped around like my old code did.

>      shift = 32 - (d2 & 0x1f);
>      if (shift == 32) mask = 0, shift = 0;
>      else mask = (1 << shift) - 1;
>      *a1 = (*a2 & mask) | (d0 << shift);

So the correct code should be:

   mask = (1 << (32 - (d2 & 0x1f))) - 1;
   *a1 = (*a2 & ~mask) | (d0 & mask);

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Andreas Schwab]

Bernardo Innocenti <bernie@develer.com> writes:

> Andreas Schwab wrote:
>> Bernardo Innocenti <bernie@develer.com> writes:
>> 
>>>Another thing.  I'm playing with libffi to see if I can get it to work
>>>on plain 68000.   Do you know a simple instruction sequence to replace
>>>this bit-field operation?
>>>
>>>   bfins   %d0,(%a1){#0,%d2}
>>>
>>>
>>>I was thinking of something like this (in pseudo-C):
>>>
>>>   mask = (1 << (d2 & 0x1f)) - 1;
>>>   *a1 = (*a2 & ~mask) | (d0 & mask);
>> The mask is wrong. The bitfield insns number the bits from MSB to LSB,
>> not
>> the other way round, as the single bit insns do.  Also, a width of 0 is
>> replaced by 32.
>   ^^^^^^^^^^^^^^
>
> This does only happen for immediate modes

No, also for non-immediate.  A bitfield can never be empty.

    Width field
      Specifies the field width, depending on Dw.
        If Dw = 0, the width field is an immediate operand; an operand
          value in the range 1 - 31 specifies a field width of 1 - 31, and
          a value of zero specifies a width of 32.
        If Dw = 1, the width field specifies a data register that contains
          the width. The value is modulo 32; values of 1 - 31 specify
          field widths of 1 - 31, and a value of zero specifies a width of
          32.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Andreas Schwab wrote:

>>>The mask is wrong. The bitfield insns number the bits from MSB to LSB,
>>>not
>>>the other way round, as the single bit insns do.  Also, a width of 0 is
>>>replaced by 32.
>> ^^^^^^^^^^^^^^
>>
>>This does only happen for immediate modes
> 
> No, also for non-immediate.  A bitfield can never be empty.
> 
>     Width field
>       Specifies the field width, depending on Dw.
>         If Dw = 0, the width field is an immediate operand; an operand
>           value in the range 1 - 31 specifies a field width of 1 - 31, and
>           a value of zero specifies a width of 32.
>         If Dw = 1, the width field specifies a data register that contains
>           the width. The value is modulo 32; values of 1 - 31 specify
>           field widths of 1 - 31, and a value of zero specifies a width of
>           32.

My copy of the manual says exactly the same... I must have mis-read it
the first time.

So emulating bfins on the 68000 is actually as complex as you said :-(


-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Peter Barada]

>My copy of the manual says exactly the same... I must have mis-read it
>the first time.
>
>So emulating bfins on the 68000 is actually as complex as you said :-(

Hence why they made it an actual instruction on the 68020 :-)

-- 
Peter Barada
peter@the-baradas.com

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Tue, Jan 06, 2004 at 12:23:34PM +0100, Bernardo Innocenti wrote:
 
> btw, since you're one of the few who can test GCC 3.4 on m68k-linux,
> would you mind to review some of these PRs?  I've recently checked
> some of them to see if I could help, but (un)fortunately none of
> them affect my targets:
> 
> http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=m68k&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED

looking through it, I can try the perl bug again but the other
bugs are either out of reach at this stage or not linux.

If I find time I will try to look at the bootstrapping problem.

> >>Hmmm... I'd suspect anything that changes m68k.md or the target
> >>hooks in m68k.h.  Perhaps linux.h overrides something that
> >>interacts with register allocation?
> >
> >Linux has different register usage for function call returns
> >but only scratch registers are involved. Other than that there
> >is nothing close to suspicious.
> 
> Then all m68k targets should be seing the same ICE, which is not
> the case.

possibly not many people with m68k targets do bootstrapping
very often nowadays - afaics only debian-m68k.

Eg the warning you have just recetnly fixed in CVS would make
every bootstrap attempt fail on all m68k plattforms, not just
linux.

Richard

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:

>>Then all m68k targets should be seing the same ICE, which is not
>>the case.
> 
> possibly not many people with m68k targets do bootstrapping
> very often nowadays - afaics only debian-m68k.
> 
> Eg the warning you have just recetnly fixed in CVS would make
> every bootstrap attempt fail on all m68k plattforms, not just
> linux.

I've been building full m68k cross-toolchains from CVS for
m68k-elf and m68k-uclinux for a lot of time.

I don't see how it can be different from bootstrapping a native
compiler.  You explicitly cnfigured with --enable-werror, didn't you?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Wed, Jan 07, 2004 at 01:12:18AM +0100, Bernardo Innocenti wrote:
> Richard Zidlicky wrote:
> 
> >>Then all m68k targets should be seing the same ICE, which is not
> >>the case.
> >
> >possibly not many people with m68k targets do bootstrapping
> >very often nowadays - afaics only debian-m68k.
> >
> >Eg the warning you have just recetnly fixed in CVS would make
> >every bootstrap attempt fail on all m68k plattforms, not just
> >linux.
> 
> I've been building full m68k cross-toolchains from CVS for
> m68k-elf and m68k-uclinux for a lot of time.
> 
> I don't see how it can be different from bootstrapping a native
> compiler.

the crosscompiler can compile many things correctly but happens
to miscompile itself. Note that while the crosscompiler correctly
builds all of libgcc and libstdc, the native compiler breaks
on the 3 or so compilation unit of libgcc.

>  You explicitly cnfigured with --enable-werror, didn't you?

no. I had to override Makefile even to get past this. Apparently
"make bootstrap" does it by default

Richard

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:

>>I've been building full m68k cross-toolchains from CVS for
>>m68k-elf and m68k-uclinux for a lot of time.
>>
>>I don't see how it can be different from bootstrapping a native
>>compiler.
> 
> the crosscompiler can compile many things correctly but happens
> to miscompile itself. Note that while the crosscompiler correctly
> builds all of libgcc and libstdc, the native compiler breaks
> on the 3 or so compilation unit of libgcc.

With GCC 3.3.2 and on the 3.3 branch, I've found an ICE compiling
uClibc's printf.c with -O1 or greater:

m68k-elf-gcc  -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing  -Os  -Wa,--bitwise-or -I/usr/local/src/uclinux-tools/linux-2.4.x/include -m5200   -fno-builtin -nostdinc -D_LIBC -I../../include -I. -I/usr/local/lib/gcc-lib/m68k-elf/3.3.2/include -DNDEBUG -msoft-float -DL__fpmaxtostr printf.c -c -o _fpmaxtostr.o
printf.c: In function `_fpmaxtostr':
printf.c:2451: error: insn does not satisfy its constraints:
(insn 1379 542 543 38 (nil) (set (reg:QI 8 %a0)
        (mem:QI (plus:SI (reg/f:SI 14 %a6)
                        (const_int -209 [0xffffff2f])) [0 mode S1 A8])) 37 {*m68k.md:1060} (nil)
                            (nil))
printf.c:2451: internal compiler error: in reload_cse_simplify_operands, at reload1.c:8345

This is the only place in all the uClinux source base that triggers
an ICE.  The bug disappeared in 3.4 with no obvious fixes in m68k.md.

It really, really smells like a latent bug in code-generation that's
only triggered by the m68k backend in rare circumstances.  Perhaps
it's caused by memory trashing or an uninitialized value.

Is it just possible that this bug is still plaguing 3.4 and is now
showing up in some different way on m68k-linux?


>> You explicitly cnfigured with --enable-werror, didn't you?
> 
> no. I had to override Makefile even to get past this. Apparently
> "make bootstrap" does it by default

Oh, I see.  Actually, there's a comment in configure.in that says
-Werror is enabled by default on interim snapshots.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Andreas Schwab]

Bernardo Innocenti <bernie@develer.com> writes:

> printf.c:2451: error: insn does not satisfy its constraints:
> (insn 1379 542 543 38 (nil) (set (reg:QI 8 %a0)
>         (mem:QI (plus:SI (reg/f:SI 14 %a6)
>                         (const_int -209 [0xffffff2f])) [0 mode S1 A8])) 37 {*m68k.md:1060} (nil)
>                             (nil))

This tries to move a QImode from memory to an address register.  m68k.md
has this pattern for movqi:

(define_expand "movqi"
  [(set (match_operand:QI 0 "nonimmediate_operand" "")
        (match_operand:QI 1 "general_src_operand" ""))]
  ""
  "")

(define_insn ""
  [(set (match_operand:QI 0 "nonimmediate_operand" "=d,*a,m")
	(match_operand:QI 1 "general_src_operand" "dmSi*a,di*a,dmSi"))]
  "!TARGET_COLDFIRE"
  "* return output_move_qimode (operands);")

And indeed this combination of operands is not allowed by the constraints.
Shouldn't the define_expand reject this in the first place, or is there
some other mechanism to tell the reload pass not to generate such an insn?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Andreas Schwab wrote:

>>printf.c:2451: error: insn does not satisfy its constraints:
>>(insn 1379 542 543 38 (nil) (set (reg:QI 8 %a0)
>>        (mem:QI (plus:SI (reg/f:SI 14 %a6)
>>                        (const_int -209 [0xffffff2f])) [0 mode S1 A8])) 37 {*m68k.md:1060} (nil)
>>                            (nil))
> 
> This tries to move a QImode from memory to an address register.  m68k.md
> has this pattern for movqi:
> 
> (define_expand "movqi"
>   [(set (match_operand:QI 0 "nonimmediate_operand" "")
>         (match_operand:QI 1 "general_src_operand" ""))]
>   ""
>   "")
> 
> (define_insn ""
>   [(set (match_operand:QI 0 "nonimmediate_operand" "=d,*a,m")
> 	(match_operand:QI 1 "general_src_operand" "dmSi*a,di*a,dmSi"))]
>   "!TARGET_COLDFIRE"
>   "* return output_move_qimode (operands);")

You meant to quote the TARGET_COLDFIRE version?  The ICE happens
with -m5200.

> And indeed this combination of operands is not allowed by the constraints.
> Shouldn't the define_expand reject this in the first place, or is there
> some other mechanism to tell the reload pass not to generate such an insn?

Sorry, I think I don't fully understand how the code generation pass
works.  In gccint, I read:

   Every RTL insn emitted by a `define_expand' must match some
   `define_insn' in the machine description.  Otherwise, the compiler will
   crash when trying to generate code for the insn or trying to optimize
   it.

So it means that once you've defined the "movqi" pattern, you must
provide enough insns to satisfy all possible combinations of operands.

Could we fix it by adding a new insn for TARGET_COLDFIRE with relaxed
constraints, implemented using a longer/slower sequence of m68k
instructions?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Andreas Schwab]

Bernardo Innocenti <bernie@develer.com> writes:

> Andreas Schwab wrote:
>
>>>printf.c:2451: error: insn does not satisfy its constraints:
>>>(insn 1379 542 543 38 (nil) (set (reg:QI 8 %a0)
>>>        (mem:QI (plus:SI (reg/f:SI 14 %a6)
>>>                        (const_int -209 [0xffffff2f])) [0 mode S1 A8])) 37 {*m68k.md:1060} (nil)
>>>                            (nil))
>> This tries to move a QImode from memory to an address register.  m68k.md
>> has this pattern for movqi:
>> (define_expand "movqi"
>>   [(set (match_operand:QI 0 "nonimmediate_operand" "")
>>         (match_operand:QI 1 "general_src_operand" ""))]
>>   ""
>>   "")
>> (define_insn ""
>>   [(set (match_operand:QI 0 "nonimmediate_operand" "=d,*a,m")
>> 	(match_operand:QI 1 "general_src_operand" "dmSi*a,di*a,dmSi"))]
>>   "!TARGET_COLDFIRE"
>>   "* return output_move_qimode (operands);")
>
> You meant to quote the TARGET_COLDFIRE version?  The ICE happens
> with -m5200.

Ok, I thought it was the other way round, but the argument equally holds
for this case.  And the potential for the bug also exists for
!TARGET_COLDFIRE, IMHO.

>> And indeed this combination of operands is not allowed by the constraints.
>> Shouldn't the define_expand reject this in the first place, or is there
>> some other mechanism to tell the reload pass not to generate such an insn?
>
> Sorry, I think I don't fully understand how the code generation pass
> works.  In gccint, I read:
>
>    Every RTL insn emitted by a `define_expand' must match some
>    `define_insn' in the machine description.  Otherwise, the compiler will
>    crash when trying to generate code for the insn or trying to optimize
>    it.
>
> So it means that once you've defined the "movqi" pattern, you must
> provide enough insns to satisfy all possible combinations of operands.

But named patterns are special, and movM patterns are even more special:

     Second, these patterns are not used solely in the RTL generation
     pass.  Even the reload pass can generate move insns to copy values
     from stack slots into temporary registers.  When it does so, one
     of the operands is a hard register and the other is an operand
     that can need to be reloaded into a register.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Peter Barada]

> printf.c:2451: error: insn does not satisfy its constraints:
> (insn 1379 542 543 38 (nil) (set (reg:QI 8 %a0)
>         (mem:QI (plus:SI (reg/f:SI 14 %a6)
>                         (const_int -209 [0xffffff2f])) [0 mode S1 A8])) 37 {*m68k.md:1060} (nil)
>                             (nil))

I've reported this before.  See <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5753>

This bug needs to be reopened.

-- 
Peter Barada
peter@the-baradas.com

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Wed, Jan 07, 2004 at 09:53:14PM +0100, Bernardo Innocenti wrote:
> Richard Zidlicky wrote:
> 
> >>I've been building full m68k cross-toolchains from CVS for
> >>m68k-elf and m68k-uclinux for a lot of time.
> >>
> >>I don't see how it can be different from bootstrapping a native
> >>compiler.
> >
> >the crosscompiler can compile many things correctly but happens
> >to miscompile itself. Note that while the crosscompiler correctly
> >builds all of libgcc and libstdc, the native compiler breaks
> >on the 3 or so compilation unit of libgcc.
> 
> With GCC 3.3.2 and on the 3.3 branch, I've found an ICE compiling
> uClibc's printf.c with -O1 or greater:
...
...
> This is the only place in all the uClinux source base that triggers
> an ICE.  The bug disappeared in 3.4 with no obvious fixes in m68k.md.

like many other m68k bugs before.

> It really, really smells like a latent bug in code-generation that's
> only triggered by the m68k backend in rare circumstances.  Perhaps
> it's caused by memory trashing or an uninitialized value.
> 
> Is it just possible that this bug is still plaguing 3.4 and is now
> showing up in some different way on m68k-linux?

quite possible but veryfing that would be even more work than "simply"
debugging the current problem.
The bootstrapping problem apparently goes away if the compiler is
compiled with different optimisation settings, doing a little more
experimentation here.
Next I will compare dumped RTL info from the native and crosscompiler,
should give some clue to see what part of the compiler is miscompiled.

Richard

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Wed, Jan 07, 2004 at 09:53:14PM +0100, Bernardo Innocenti wrote:
Hi,

I am now comparing the rtl dumps of the lshrdi example to figure
out where to start debugging. 2 compilers built from identical
source and config, the native one is somewhere miscompiled.

- in *.i.00.cgraph the whole "Final callgraph:" section  is missing in the
  dump generated by the native compiler
- in *.i.01.rtl the first insns are particularly suspect:

--- native/xx.i.01.rtl  2004-01-08 20:35:55.000000000 +0100
+++ xc/xx.i.01.rtl      2004-01-08 21:30:29.000000000 +0100
@@ -5,198 +5,197 @@
 
 (note 2 1 3 NOTE_INSN_DELETED)
 
-(insn 3 2 4 (set (reg:SI 31)
-        (reg/f:SI 25 virtual-incoming-args)) -1 (nil)
-    (nil))
-
-(insn 4 3 5 (set (reg/v:DI 32 [ u ])
-        (mem/f:DI (reg:SI 31) [2 u+0 S8 A16])) -1 (nil)
-    (nil))
+(insn 3 2 4 (set (reg/v:DI 31 [ u ])
+        (mem/f:DI (reg/f:SI 25 virtual-incoming-args) [2 u+0 S8 A16])) -1 (nil)
+    (expr_list:REG_EQUIV (mem/f:DI (reg/f:SI 25 virtual-incoming-args) [2 u+0 S
8 A16])
+        (nil)))
 
-(insn 5 4 6 (set (reg/v:SI 33 [ b ])
-        (mem/f:SI (plus:SI (reg:SI 31)
+(insn 4 3 5 (set (reg/v:SI 32 [ b ])
+        (mem/f:SI (plus:SI (reg/f:SI 25 virtual-incoming-args)
                 (const_int 8 [0x8])) [3 b+0 S4 A16])) -1 (nil)
-    (nil))
+    (expr_list:REG_EQUIV (mem/f:SI (plus:SI (reg/f:SI 25 virtual-incoming-args)
+                (const_int 8 [0x8])) [3 b+0 S4 A16])
+        (nil)))

Where does that difference come from?

Do I need to debug the rtl generation, or even before that?

The above diffs may suggest that something is wrong with the
improved prologue/epilogue generation on m68k but since this
is a miscompiled compiler it could be very easilly pure
coincidence.

Richard

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:

> The above diffs may suggest that something is wrong with the
> improved prologue/epilogue generation on m68k but since this
> is a miscompiled compiler it could be very easilly pure
> coincidence.

A non-trivial side-effect of the new frame generation code
is that, when -fomit-frame-pointer is enabled, there's no
longer a wasted slot where the frame pointer would normally
be saved.

This change could affect buggy user code containing
off-by-one stack overflows.

IIRC, -O2 implies -fomit-frame-pointer on the m68k.  Try
building with '-O2 -fno-omit-frame-pointer' and see what
happens.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Thu, Jan 08, 2004 at 10:58:31PM +0100, Bernardo Innocenti wrote:
> Richard Zidlicky wrote:
> 
> >The above diffs may suggest that something is wrong with the
> >improved prologue/epilogue generation on m68k but since this
> >is a miscompiled compiler it could be very easilly pure
> >coincidence.
> 
> A non-trivial side-effect of the new frame generation code
> is that, when -fomit-frame-pointer is enabled, there's no
> longer a wasted slot where the frame pointer would normally
> be saved.
> 
> This change could affect buggy user code containing
> off-by-one stack overflows.

Is it possible that there is some endianness or similar issue
inside the new frame generation code? Bitfields or whatever might
cause portability problems?

> IIRC, -O2 implies -fomit-frame-pointer on the m68k. 

it doesnt imply that. I have already tried both variants, no
visible difference wrt this bug.

Richard

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:

>>This change could affect buggy user code containing
>>off-by-one stack overflows.
> 
> Is it possible that there is some endianness or similar issue
> inside the new frame generation code? Bitfields or whatever might
> cause portability problems?

No, it shouldn't be possible.  There might some obscure bug somewhere
in corner cases such as functions with big frames or functions with
strange attributes...

The new code couldn't be regtested with dejagnu because there is
no m68k simulator in GDB and there were too many issues with remote
testsuite execution on embedded ColdFire boards.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Fri, Jan 09, 2004 at 04:22:18AM +0100, Bernardo Innocenti wrote:
> Richard Zidlicky wrote:
> 
> >>This change could affect buggy user code containing
> >>off-by-one stack overflows.
> >
> >Is it possible that there is some endianness or similar issue
> >inside the new frame generation code? Bitfields or whatever might
> >cause portability problems?
> 
> No, it shouldn't be possible.  There might some obscure bug somewhere
> in corner cases such as functions with big frames or functions with
> strange attributes...

even if it doesnt bomb it generates code like this:
__cmpdi2:
.LFB38:
	.file 1 "../../gcc-3.4-20031210/gcc/libgcc2.c"
	.loc 1 1068 0
	pea (%a6)
	move.l %sp,%a6
.LCFI0:
	move.l %d2,-(%sp)
.LCFI1:
	lea (8,%a6),%a0      !!!!!!!!
	move.l (%a0),%d0
	move.l 4(%a0),%d1
.....

The use of %a0 is not incorrect but completely unnecessary.. same
optimisation settings etc again. What would cause this kind of code
get generated? Wrong cost estimate? Some comparison against +/32K
run amuck?

> The new code couldn't be regtested with dejagnu because there is
> no m68k simulator in GDB and there were too many issues with remote
> testsuite execution on embedded ColdFire boards.

If you want to debug this it should be possible to get an account
on some of the m68k boxes of the Debian project, 
mail debian-68k@lists.debian.org


Richard

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:

>>No, it shouldn't be possible.  There might some obscure bug somewhere
>>in corner cases such as functions with big frames or functions with
>>strange attributes...
> 
> even if it doesnt bomb it generates code like this:
> __cmpdi2:
> .LFB38:
> 	.file 1 "../../gcc-3.4-20031210/gcc/libgcc2.c"
> 	.loc 1 1068 0
> 	pea (%a6)
> 	move.l %sp,%a6

This is equivalent to:

	link #0,a6

It's done only with -m68040 because it's faster.

> .LCFI0:
> 	move.l %d2,-(%sp)
> .LCFI1:
> 	lea (8,%a6),%a0      !!!!!!!!
> 	move.l (%a0),%d0
> 	move.l 4(%a0),%d1
> .....
> 
> The use of %a0 is not incorrect but completely unnecessary.. same
> optimisation settings etc again. What would cause this kind of code
> get generated? Wrong cost estimate? Some comparison against +/32K
> run amuck?

I believe this is how GCC has always worked.  Unless you specify
-fomit-frame-pointer, a6 will be loaded with sp in function
prologue, even if the frame size is 0.  This is done because older
debuggers relied on it in order to find local variables.

Of course, we could change the default for m68k to imply
-fomit-frame-pointer with -O, as described in the manual:

 `-O' also turns on `-fomit-frame-pointer' on machines where doing
 so does not interfere with debugging.


>>The new code couldn't be regtested with dejagnu because there is
>>no m68k simulator in GDB and there were too many issues with remote
>>testsuite execution on embedded ColdFire boards.
> 
> If you want to debug this it should be possible to get an account
> on some of the m68k boxes of the Debian project, 
> mail debian-68k@lists.debian.org

Good idea!  I've just asked them.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Henderson]

On Sat, Jan 10, 2004 at 10:08:54PM +0100, Bernardo Innocenti wrote:
> > 	lea (8,%a6),%a0      !!!!!!!!
> > 	move.l (%a0),%d0
> ...
> I believe this is how GCC has always worked.  Unless you specify
> -fomit-frame-pointer...

No, he means why not

	move.l (8,%a6),%d0

and dispense with the lea entirely.


r~

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Henderson wrote:
> On Sat, Jan 10, 2004 at 10:08:54PM +0100, Bernardo Innocenti wrote:
> 
>>>	lea (8,%a6),%a0      !!!!!!!!
>>>	move.l (%a0),%d0
>>
>>...
>>I believe this is how GCC has always worked.  Unless you specify
>>-fomit-frame-pointer...
> 
> No, he means why not
> 
> 	move.l (8,%a6),%d0
> 
> and dispense with the lea entirely.

Yeah, it really sucks... but:

 - A sub-optimal instruction sequence can't be responsable for
   the m68k-linux bootstrap failure in "make compare".

 - I strongly doubt any of the m68k changes done in the 3.4
   cycle could have introduced such a bug;


Just an idea: m68k is the only cc0 target capable of an
hosted bootstrap.  Is it possible that middle-end changes
have subtly broken cc0 targets without anyone noticing
except on the m68k?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Sun, Jan 11, 2004 at 07:32:54AM +0100, Bernardo Innocenti wrote:
> Richard Henderson wrote:
> >On Sat, Jan 10, 2004 at 10:08:54PM +0100, Bernardo Innocenti wrote:
> >
> >>>	lea (8,%a6),%a0      !!!!!!!!
> >>>	move.l (%a0),%d0
> >>
> >>...
> >>I believe this is how GCC has always worked.  Unless you specify
> >>-fomit-frame-pointer...
> >
> >No, he means why not
> >
> >	move.l (8,%a6),%d0
> >
> >and dispense with the lea entirely.
> 
> Yeah, it really sucks... but:
> 
> - A sub-optimal instruction sequence can't be responsable for
>   the m68k-linux bootstrap failure in "make compare".

that is of course correct, it was simply the first anomaly
in the rtl dumps that I have noticed so I am trying to see
where it comes from.

Just to recap: this anomaly occurs only when the compilation
is done on native m68k and appears to be stable between the last
month snapshots. Crosscompilation produces the expected code.
Turning optimization off when producing the native cc1 fixes
the problem. I am currently looking which module breaks
when optimised - none of the obvious candidates so it is
search by bruteforce now.

> Just an idea: m68k is the only cc0 target capable of an
> hosted bootstrap.  Is it possible that middle-end changes
> have subtly broken cc0 targets without anyone noticing
> except on the m68k?

what is cc0?

Richard

Re: m68k bootstrapping broken

[Andreas Schwab]

Richard Zidlicky <rz@linux-m68k.org> writes:

> Just to recap: this anomaly occurs only when the compilation
> is done on native m68k and appears to be stable between the last
> month snapshots. Crosscompilation produces the expected code.
> Turning optimization off when producing the native cc1 fixes
> the problem. I am currently looking which module breaks
> when optimised - none of the obvious candidates so it is
> search by bruteforce now.

FWIW, I can reproduce the ICE in __lshrdi3 with a compiler that was
built with a ppc->m68k cross compiler.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:

>>- A sub-optimal instruction sequence can't be responsable for
>>  the m68k-linux bootstrap failure in "make compare".
> 
> that is of course correct, it was simply the first anomaly
> in the rtl dumps that I have noticed so I am trying to see
> where it comes from.

Oh, I didn't realize the code in question was actually one
of the differences between stage2 and stage3.


>>Just an idea: m68k is the only cc0 target capable of an
>>hosted bootstrap.  Is it possible that middle-end changes
>>have subtly broken cc0 targets without anyone noticing
>>except on the m68k?
> 
> what is cc0?

It's described shortly here: <http://gcc.gnu.org/simtest-howto.html> .
The gccint manual contains the details.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Henderson]

On Sun, Jan 11, 2004 at 07:32:54AM +0100, Bernardo Innocenti wrote:
> Just an idea: m68k is the only cc0 target capable of an
> hosted bootstrap.  Is it possible that middle-end changes
> have subtly broken cc0 targets without anyone noticing
> except on the m68k?

Possible, yes.  It wouldn't be my first guess though.


r~

Re: m68k bootstrapping broken

[Matt Thomas]

At 01:11 AM 1/11/2004, Richard Henderson wrote:
>On Sun, Jan 11, 2004 at 07:32:54AM +0100, Bernardo Innocenti wrote:
> > Just an idea: m68k is the only cc0 target capable of an
> > hosted bootstrap.  Is it possible that middle-end changes
> > have subtly broken cc0 targets without anyone noticing
> > except on the m68k?
>
>Possible, yes.  It wouldn't be my first guess though.

VAX (a cc0 target) is also quite broken in gcc 3.4.  I've been at a
loss to figure out why.  (And VAX could do a hosted bootstrap if gcc
wasn't so broken).


-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.

VAX support (was: m68k bootstrapping broken)

[Jan-Benedict Glaw]

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

On Sun, 2004-01-11 10:05:59 -0800, Matt Thomas <matt@3am-software.com>
wrote in message <6.0.1.1.2.20040111100346.04bf15e8@3am-software.com>:
> At 01:11 AM 1/11/2004, Richard Henderson wrote:
> >On Sun, Jan 11, 2004 at 07:32:54AM +0100, Bernardo Innocenti wrote:
> >> Just an idea: m68k is the only cc0 target capable of an
> >> hosted bootstrap.  Is it possible that middle-end changes
> >> have subtly broken cc0 targets without anyone noticing
> >> except on the m68k?
> >Possible, yes.  It wouldn't be my first guess though.
> 
> VAX (a cc0 target) is also quite broken in gcc 3.4.  I've been at a
> loss to figure out why.  (And VAX could do a hosted bootstrap if gcc
> wasn't so broken).

I'd *love* to see VAX cured! For vax-linux, we currently use a quite
dated compiler which glibc refuses to build with...

Rumors tell me that it isn't much work to introduce vax-linux support
(after the VAX backend basically works again). I'm not really into gcc,
but where is (currently) the exact problem with VAX? Maybe I can at
least understand it:)

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Sun, Jan 11, 2004 at 07:32:54AM +0100, Bernardo Innocenti wrote:
> Richard Henderson wrote:
> >On Sat, Jan 10, 2004 at 10:08:54PM +0100, Bernardo Innocenti wrote:
> >
> >>>	lea (8,%a6),%a0      !!!!!!!!
> >>>	move.l (%a0),%d0
> >>
> >>...
> >>I believe this is how GCC has always worked.  Unless you specify
> >>-fomit-frame-pointer...
> >
> >No, he means why not
> >
> >	move.l (8,%a6),%d0
> >
> >and dispense with the lea entirely.

here is what the brute force search yields:

- ICE on lshrdi occurs when insn-recog.o is crosscompiled with -O2

- argpointer elimination breaks when regclass.o is crosscompiled with -O2

Any guess how regclass.o might influence argpointer elimination?

Richard

Re: m68k bootstrapping broken

[Andreas Schwab]

Richard Zidlicky <rz@linux-m68k.org> writes:

> here is what the brute force search yields:
>
> - ICE on lshrdi occurs when insn-recog.o is crosscompiled with -O2

Compiling with -fno-unit-at-a-time fixes this.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Andreas Schwab]

Richard Zidlicky <rz@linux-m68k.org> writes:

> here is what the brute force search yields:
>
> - ICE on lshrdi occurs when insn-recog.o is crosscompiled with -O2

I've found the bug: for all CONST_METHODs except MOVQ and MOVL we
don't generate a useful CC, but we don't record this fact.  Could you
please test this patch?

Thanks, Andreas.

2004-01-11  Andreas Schwab  <schwab@suse.de>

	* config/m68k/m68k.c (output_move_const_into_data_reg): Clear cc
	status for CONST_METHODs other than MOVQ and MOVL .

Index: gcc/config/m68k/m68k.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/m68k/m68k.c,v
retrieving revision 1.122
diff -u -a -p -a -u -p -r1.122 gcc/config/m68k/m68k.c
--- gcc/config/m68k/m68k.c	5 Jan 2004 04:13:49 -0000	1.122
+++ gcc/config/m68k/m68k.c	11 Jan 2004 20:03:39 -0000
@@ -1669,10 +1669,23 @@ m68k_rtx_costs (rtx x, int code, int out
 const char *
 output_move_const_into_data_reg (rtx *operands)
 {
-  int i;
+  HOST_WIDE_INT i;
+  CONST_METHOD m;
 
   i = INTVAL (operands[1]);
-  switch (const_method (operands[1]))
+  m = const_method (operands[1]);
+  switch (m)
+    {
+    case MOVQ:
+    case MOVL:
+      break;
+    default:
+      /* All other methods don't produce a useful cc.  */
+      CC_STATUS_INIT;
+      break;
+    }
+
+  switch (m)
     {
     case MOVQ :
       return "moveq %1,%0";

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Andreas Schwab]

Andreas Schwab <schwab@suse.de> writes:

> Richard Zidlicky <rz@linux-m68k.org> writes:
>
>> here is what the brute force search yields:
>>
>> - ICE on lshrdi occurs when insn-recog.o is crosscompiled with -O2
>
> I've found the bug: for all CONST_METHODs except MOVQ and MOVL we
> don't generate a useful CC, but we don't record this fact.  Could you
> please test this patch?

I checked again, SWAP will also produce a correct cc, here is an
updated patch.

Andreas.

2004-01-11  Andreas Schwab  <schwab@suse.de>

	* config/m68k/m68k.c (output_move_const_into_data_reg): Clear cc
	status for NOTB/NOTW/NEGW methods.

Index: gcc/config/m68k/m68k.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/m68k/m68k.c,v
retrieving revision 1.122
diff -u -a -p -a -u -p -r1.122 gcc/config/m68k/m68k.c
--- gcc/config/m68k/m68k.c	5 Jan 2004 04:13:49 -0000	1.122
+++ gcc/config/m68k/m68k.c	11 Jan 2004 20:21:56 -0000
@@ -1677,12 +1677,15 @@ output_move_const_into_data_reg (rtx *op
     case MOVQ :
       return "moveq %1,%0";
     case NOTB :
+      CC_STATUS_INIT;
       operands[1] = GEN_INT (i ^ 0xff);
       return "moveq %1,%0\n\tnot%.b %0";
     case NOTW :
+      CC_STATUS_INIT;
       operands[1] = GEN_INT (i ^ 0xffff);
       return "moveq %1,%0\n\tnot%.w %0";
     case NEGW :
+      CC_STATUS_INIT;
       return "moveq %#-128,%0\n\tneg%.w %0";
     case SWAP :
       {

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Andreas Schwab wrote:

> 2004-01-11  Andreas Schwab  <schwab@suse.de>
> 
> 	* config/m68k/m68k.c (output_move_const_into_data_reg): Clear cc
> 	status for NOTB/NOTW/NEGW methods.

Thank you!  I'm going to test your patch on m68k-uclinux.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Sun, Jan 11, 2004 at 09:27:17PM +0100, Andreas Schwab wrote:
> Andreas Schwab <schwab@suse.de> writes:

> > I've found the bug: for all CONST_METHODs except MOVQ and MOVL we
> > don't generate a useful CC, but we don't record this fact.  Could you
> > please test this patch?
> 
> I checked again, SWAP will also produce a correct cc, here is an
> updated patch.

.. I assume this patch fully supersedes the previous? The 
-  int i;
+  HOST_WIDE_INT i;
change isnt in the new one so I wasnt 100% sure.

that fixes ICE, doesnt seem to affect argpointer elimination problem.
Bootstrapping underway.

Richard

> 2004-01-11  Andreas Schwab  <schwab@suse.de>
> 
> 	* config/m68k/m68k.c (output_move_const_into_data_reg): Clear cc
> 	status for NOTB/NOTW/NEGW methods.
> 

Re: m68k bootstrapping broken

[Andreas Schwab]

Richard Zidlicky <rz@linux-m68k.org> writes:

> On Sun, Jan 11, 2004 at 09:27:17PM +0100, Andreas Schwab wrote:
>> Andreas Schwab <schwab@suse.de> writes:
>
>> > I've found the bug: for all CONST_METHODs except MOVQ and MOVL we
>> > don't generate a useful CC, but we don't record this fact.  Could you
>> > please test this patch?
>> 
>> I checked again, SWAP will also produce a correct cc, here is an
>> updated patch.
>
> .. I assume this patch fully supersedes the previous?

Yes, this is right.

> The 
> -  int i;
> +  HOST_WIDE_INT i;
> change isnt in the new one so I wasnt 100% sure.

This wasn't intented to be included.

>
> that fixes ICE, doesnt seem to affect argpointer elimination problem.
> Bootstrapping underway.

Thanks, Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Richard Zidlicky]

Hi,

bootstrapping with "languages=c" just completed. The argpointer
elimination problem still remains - crosscompiler does it correctly,
bootstrapped compiler doesnt.

The infinite recrusion with when compiling cp-demangle also remains.

Richard

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:
> Hi,
> 
> bootstrapping with "languages=c" just completed.

Did you get this warning?

stage1/xgcc -Bstage1/ -B/home/bernie/src/m68k-netbsdelf-HEAD-install/m68k-unknown-netbsdelf1.6.2./bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
 -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition -Werror -fno-common   -DHAVE_CONFIG_H    -I. -I. -I../../combined-HEAD/gcc -I../../combined-HEAD/gcc
/. -I../../combined-HEAD/gcc/../include  ../../combined-HEAD/gcc/bb-reorder.c -o bb-reorder.o
../../combined-HEAD/gcc/bb-reorder.c: In function `reorder_basic_blocks':
../../combined-HEAD/gcc/bb-reorder.c:186: warning: 'count_threshold' might be used uninitialized in this function
gmake[1]: *** [bb-reorder.o] Error 1
gmake[1]: Leaving directory `/home/bernie/src/m68k-netbsdelf-HEAD-build/gcc'
gmake: *** [stage2_build] Error 2


I get it on m68k-netbsd while building stage2 with the stage1 compiler.
I can't reproduce it on i386-pc-linux, and this warning is clearly a
deficiency in control flow analysis, something that isn't supposed to
vary on a per-host basis.

> The argpointer
> elimination problem still remains - crosscompiler does it correctly,
> bootstrapped compiler doesnt.

There definitely must be yet another bug besides the one found by
Andreas.  I'm still running make bootstrap on my m68k-netbsd account,
so I can't confirm your findings :-(


> The infinite recrusion with when compiling cp-demangle also remains.

Have you tried with a newer GCC snapshot?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Wed, Jan 14, 2004 at 12:25:22AM +0100, Bernardo Innocenti wrote:
> Richard Zidlicky wrote:
> >Hi,
> >
> >bootstrapping with "languages=c" just completed.
> 
> Did you get this warning?
> 
> stage1/xgcc -Bstage1/ 
> -B/home/bernie/src/m68k-netbsdelf-HEAD-install/m68k-unknown-netbsdelf1.6.2./bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition 
> -Werror -fno-common   -DHAVE_CONFIG_H    -I. -I. -I../../combined-HEAD/gcc 
> -I../../combined-HEAD/gcc
> /. -I../../combined-HEAD/gcc/../include  
> ../../combined-HEAD/gcc/bb-reorder.c -o bb-reorder.o
> ../../combined-HEAD/gcc/bb-reorder.c: In function `reorder_basic_blocks':
> ../../combined-HEAD/gcc/bb-reorder.c:186: warning: 'count_threshold' might 
> be used uninitialized in this function
> gmake[1]: *** [bb-reorder.o] Error 1
> gmake[1]: Leaving directory `/home/bernie/src/m68k-netbsdelf-HEAD-build/gcc'
> gmake: *** [stage2_build] Error 2
> 

havent seen it in my log.


> >The infinite recrusion with when compiling cp-demangle also remains.
> 
> Have you tried with a newer GCC snapshot?

still on 20040107, this one seems to have at least 2 bugs I havent
seen in the previous snapshot :(

Richard

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:
> On Wed, Jan 14, 2004 at 12:25:22AM +0100, Bernardo Innocenti wrote:
>>Richard Zidlicky wrote:
>>
>>>Hi,
>>>
>>>bootstrapping with "languages=c" just completed.
>>
>>Did you get this warning?
>>
>>stage1/xgcc -Bstage1/ 
>>-B/home/bernie/src/m68k-netbsdelf-HEAD-install/m68k-unknown-netbsdelf1.6.2./bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
>>-Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition 
>>-Werror -fno-common   -DHAVE_CONFIG_H    -I. -I. -I../../combined-HEAD/gcc 
>>-I../../combined-HEAD/gcc
>>/. -I../../combined-HEAD/gcc/../include  
>>../../combined-HEAD/gcc/bb-reorder.c -o bb-reorder.o
>>../../combined-HEAD/gcc/bb-reorder.c: In function `reorder_basic_blocks':
>>../../combined-HEAD/gcc/bb-reorder.c:186: warning: 'count_threshold' might 
>>be used uninitialized in this function
>>gmake[1]: *** [bb-reorder.o] Error 1
>>gmake[1]: Leaving directory `/home/bernie/src/m68k-netbsdelf-HEAD-build/gcc'
>>gmake: *** [stage2_build] Error 2
> 
> havent seen it in my log.

Well, this is *extremely* odd.  I don't see it on i386-linux either, and it's
still there with Adreas patch applied in both stage1 and stage2 compilers:

stage2/xgcc -Bstage2/ -B/home/bernie/src/m68k-netbsdelf-HEAD-install/m68k-unknown-netbsdelf1.6.2./bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition -fno-common   -DHAVE_CONFIG_H    -I. -I. -I../../combined-HEAD/gcc -I../../combined-HEAD/gcc/. -I../../combined-HEAD/gcc/../include  ../../combined-HEAD/gcc/bb-reorder.c -o bb-reorder.o
../../combined-HEAD/gcc/bb-reorder.c: In function `reorder_basic_blocks':
../../combined-HEAD/gcc/bb-reorder.c:186: warning: 'count_threshold' might be used uninitialized in this function


Could you please try running this exact command line on your system to
make absolutely sure it's only happening on m68k-netbsdelf?

I'm puzzled.

>>Have you tried with a newer GCC snapshot?
> 
> still on 20040107, this one seems to have at least 2 bugs I havent
> seen in the previous snapshot :(

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Thu, Jan 15, 2004 at 12:57:47AM +0100, Bernardo Innocenti wrote:


> stage2/xgcc -Bstage2/ 
> -B/home/bernie/src/m68k-netbsdelf-HEAD-install/m68k-unknown-netbsdelf1.6.2./bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition -fno-common   -DHAVE_CONFIG_H    -I. -I. -I../../combined-HEAD/gcc -I../../combined-HEAD/gcc/. -I../../combined-HEAD/gcc/../include  ../../combined-HEAD/gcc/bb-reorder.c -o bb-reorder.o
> ../../combined-HEAD/gcc/bb-reorder.c: In function `reorder_basic_blocks':
> ../../combined-HEAD/gcc/bb-reorder.c:186: warning: 'count_threshold' might 
> be used uninitialized in this function
> 
> 
> Could you please try running this exact command line on your system to
> make absolutely sure it's only happening on m68k-netbsdelf?
> 

the line has several m68k-netbsd strings in it. Here is what I see:

stage2/xgcc -Bstage2/ -B/usr/m68k-rz-linux/bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition -Werror    -DHAVE_CONFIG_H    -I. -I. -I../../gcc-3.4-20040107/gcc -I../../gcc-3.4-20040107/gcc/. -I../../gcc-3.4-20040107/gcc/../include  ../../gcc-3.4-20040107/gcc/bb-reorder.c -o bb-reorder.o
## no warnings

Anyway - is it at all reasonable to have -Werror quit on "might be used
uninitialized" warnings? It is really very dependent on gcc version and
possibly other circumstances so it makes -Werror probably less usefull
than it could be.

Richard

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:

>>stage2/xgcc -Bstage2/ 
>>-B/home/bernie/src/m68k-netbsdelf-HEAD-install/m68k-unknown-netbsdelf1.6.2./bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition -fno-common   -DHAVE_CONFIG_H    -I. -I. -I../../combined-HEAD/gcc -I../../combined-HEAD/gcc/. -I../../combined-HEAD/gcc/../include  ../../combined-HEAD/gcc/bb-reorder.c -o bb-reorder.o
>>../../combined-HEAD/gcc/bb-reorder.c: In function `reorder_basic_blocks':
>>../../combined-HEAD/gcc/bb-reorder.c:186: warning: 'count_threshold' might 
>>be used uninitialized in this function
>>
>>
>>Could you please try running this exact command line on your system to
>>make absolutely sure it's only happening on m68k-netbsdelf?
> 
> the line has several m68k-netbsd strings in it. Here is what I see:
> 
> stage2/xgcc -Bstage2/ -B/usr/m68k-rz-linux/bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition -Werror    -DHAVE_CONFIG_H    -I. -I. -I../../gcc-3.4-20040107/gcc -I../../gcc-3.4-20040107/gcc/. -I../../gcc-3.4-20040107/gcc/../include  ../../gcc-3.4-20040107/gcc/bb-reorder.c -o bb-reorder.o
> ## no warnings

!!! That's incredible.  Richard, Andreas: how is it possible that
such a C frontend warning depends on the host OS?

I double checked and there are no differences between my copy of
bb-reorder.c and cvs HEAD.


> Anyway - is it at all reasonable to have -Werror quit on "might be used
> uninitialized" warnings? It is really very dependent on gcc version and
> possibly other circumstances so it makes -Werror probably less usefull
> than it could be.

This is indeed correct.  -Werror is only enabled in stage2+, so it
shouldn't be affected by your system compiler.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Andrew Pinski]

On Jan 15, 2004, at 10:42, Bernardo Innocenti wrote:
>
> !!! That's incredible.  Richard, Andreas: how is it possible that
> such a C frontend warning depends on the host OS?

The warning is not a C front-end warning but rather a flow control 
warning.
Most of the time this warning is right but there are problems such as 
using
subregisters and the flow control does not see that the variable is 
initialized fully so it
warns.

I think there is even a bug for something like this also.


Thanks,
Andrew Pinski

Re: m68k bootstrapping broken

[Matthias Klose]

Richard Zidlicky writes:
> On Wed, Jan 14, 2004 at 12:25:22AM +0100, Bernardo Innocenti wrote:
> > Richard Zidlicky wrote:
> > >Hi,
> > >
> > >bootstrapping with "languages=c" just completed.
> > 
> > Did you get this warning?
> > 
> > stage1/xgcc -Bstage1/ 
> > -B/home/bernie/src/m68k-netbsdelf-HEAD-install/m68k-unknown-netbsdelf1.6.2./bin/ -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
> > -Wmissing-prototypes -pedantic -Wno-long-long -Wold-style-definition 
> > -Werror -fno-common   -DHAVE_CONFIG_H    -I. -I. -I../../combined-HEAD/gcc 
> > -I../../combined-HEAD/gcc
> > /. -I../../combined-HEAD/gcc/../include  
> > ../../combined-HEAD/gcc/bb-reorder.c -o bb-reorder.o
> > ../../combined-HEAD/gcc/bb-reorder.c: In function `reorder_basic_blocks':
> > ../../combined-HEAD/gcc/bb-reorder.c:186: warning: 'count_threshold' might 
> > be used uninitialized in this function
> > gmake[1]: *** [bb-reorder.o] Error 1
> > gmake[1]: Leaving directory `/home/bernie/src/m68k-netbsdelf-HEAD-build/gcc'
> > gmake: *** [stage2_build] Error 2
> > 
> 
> havent seen it in my log.

I did see this warning for m68k-linux since March 2003. See
http://gcc.gnu.org/ml/gcc-bugs/2003-03/msg01045.html

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:
> Hi,
> 
> bootstrapping with "languages=c" just completed. The argpointer
> elimination problem still remains - crosscompiler does it correctly,
> bootstrapped compiler doesnt.

I've seen this too, but it doesn't always seem to be
related with argptr elimination.

Look at this change between stage2/mkdeps.o and
stage3/mkdeps.o:

 00000000 <munge>:
    0:  4e56 0000       linkw %fp,#0
    4:  48e7 3020       moveml %d2-%d3/%a2,%sp@-
-   8:  242e 0008       movel %fp@(8),%d2
-   c:  2442            moveal %d2,%a2
+   8:  246e 0008       moveal %fp@(8),%a2
+   c:  240a            movel %a2,%d2
    e:  91c8            subal %a0,%a0
   10:  1012            moveb %a2@,%d0
   12:  6718            beqs 2c <munge+0x2c>

Both versions are fine, but I wonder why a different
instruction pattern has been generated.

Next time I'll do a bootstrap4 to see if there are
differences between a stage3 and a stage4 compiler.


> The infinite recrusion with when compiling cp-demangle also remains.

This I've not yet seen.  Could you provide the full command line that
fails so I don't have to rebuild all of binutils with gcc 3.4?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Henderson]

On Fri, Jan 16, 2004 at 12:20:06AM +0100, Bernardo Innocenti wrote:
> Both versions are fine, but I wonder why a different
> instruction pattern has been generated.

Something in the register allocator (or subsequent passes) got miscompiled.

You'll need to look at all the dumps to find where the first difference is
found.  When you find it, that's the pass to start looking at.


r~

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Henderson wrote:
> On Fri, Jan 16, 2004 at 12:20:06AM +0100, Bernardo Innocenti wrote:
> 
>>Both versions are fine, but I wonder why a different
>>instruction pattern has been generated.
> 
> 
> Something in the register allocator (or subsequent passes) got miscompiled.
> 
> You'll need to look at all the dumps to find where the first difference is
> found.  When you find it, that's the pass to start looking at.

I've now found the time to resume working on this.  It seems
the breakage happens at RTL generation time or even before.

Also interesting is that the list of objects that fail the comparison test
is slightly different between m68k-netbsd and m68k-linux (e.g: web.o
differs only on m68k-netbsdelf).  Perhaps caused by target macro
expansion producing slightly different code.

This is what I get with bitmap.c:

diff -u stage1_dumps/bitmap.c.01.rtl stage2_dumps/bitmap.c.01.rtl
--- stage1_dumps/bitmap.c.01.rtl        2004-02-09 03:32:38.000000000 +0200
+++ stage2_dumps/bitmap.c.01.rtl        2004-02-09 03:34:52.000000000 +0200
@@ -5,163 +5,167 @@

 (note 2 1 3 NOTE_INSN_DELETED)

-(note 3 2 4 NOTE_INSN_FUNCTION_BEG)
+(insn 3 2 4 (set (reg:SI 30)
+        (reg/f:SI 25 virtual-incoming-args)) -1 (nil)
+    (nil))
+
+(note 4 3 5 NOTE_INSN_FUNCTION_BEG)

-(note 4 3 5 NOTE_INSN_DELETED)
+(note 5 4 6 NOTE_INSN_DELETED)

-(note 5 4 6 0xc03d47f8 NOTE_INSN_BLOCK_BEG)
+(note 6 5 7 0xc03d47f8 NOTE_INSN_BLOCK_BEG)

-(note 6 5 7 NOTE_INSN_DELETED)
+(note 7 6 8 NOTE_INSN_DELETED)

-(note 7 6 8 ("../../combined-3.4/gcc/bitmap.c") 158)
+(note 8 7 9 ("../../combined-3.4/gcc/bitmap.c") 158)

-(insn 8 7 9 (set (mem/f:SI (symbol_ref:SI ("bitmap_free") [flags 0x2] <var_decl 0xc03e42e6 bitmap_free>) [0 bitmap_free+0 S4 A16])
+(insn 9 8 10 (set (mem/f:SI (symbol_ref:SI ("bitmap_free") [flags 0x2] <var_decl 0xc03e42e6 bitmap_free>) [0 bitmap_free+0 S4 A16])
         (const_int 0 [0x0])) -1 (nil)
     (nil))

-(note 9 8 10 ("../../combined-3.4/gcc/bitmap.c") 159)
+(note 10 9 11 ("../../combined-3.4/gcc/bitmap.c") 159)

-(insn 10 9 11 (set (cc0)
+(insn 11 10 12 (set (cc0)
         (mem/f:SI (symbol_ref:SI ("bitmap_obstack_init") [flags 0x2] <var_decl 0xc03e4212 bitmap_obstack_init>) [0 bitmap_obstack_init+0 S4 A16])) -1 (nil)
     (nil))

[...lots of other changes...]

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Mon, Feb 09, 2004 at 02:46:03AM +0100, Bernardo Innocenti wrote:
> Richard Henderson wrote:
> >On Fri, Jan 16, 2004 at 12:20:06AM +0100, Bernardo Innocenti wrote:
> >
> >>Both versions are fine, but I wonder why a different
> >>instruction pattern has been generated.
> >
> >
> >Something in the register allocator (or subsequent passes) got miscompiled.
> >
> >You'll need to look at all the dumps to find where the first difference is
> >found.  When you find it, that's the pass to start looking at.
> 
> I've now found the time to resume working on this.

.. and I am now back from skiing :)

>  It seems
> the breakage happens at RTL generation time or even before.

can you try to compile regclass.c without optimisation to see if
it changes anything? It had an effect on another problem so it
might be related.

Richard

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:

>>I've now found the time to resume working on this.
> 
> .. and I am now back from skiing :)

Me too!  I've been skiing until yesterday ;-)


>> It seems
>>the breakage happens at RTL generation time or even before.
> 
> can you try to compile regclass.c without optimisation to see if
> it changes anything? It had an effect on another problem so it
> might be related.

I will do it as soon as possible, but I'm again short on time.
I went on vacation even though I had so much to do.  Now I'll
have to pay back...

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Sun, Feb 15, 2004 at 07:33:19PM +0100, Bernardo Innocenti wrote:
> Richard Zidlicky wrote:
> 
> >>I've now found the time to resume working on this.
> >
> >.. and I am now back from skiing :)
> 
> Me too!  I've been skiing until yesterday ;-)


> >>It seems
> >>the breakage happens at RTL generation time or even before.
> >
> >can you try to compile regclass.c without optimisation to see if
> >it changes anything? It had an effect on another problem so it
> >might be related.

in the meantime I tried a more recent snapshot and got tons
of differences in the comparison again.. this may perhaps
make the bug easier to hunt down. For now I am looking at
various testsuites tfind something easy.

Richard

Re: m68k bootstrapping broken

[Andreas Schwab]

Bernardo Innocenti <bernie@develer.com> writes:

> Richard Zidlicky wrote:
>> Hi,
>> bootstrapping with "languages=c" just completed. The argpointer
>> elimination problem still remains - crosscompiler does it correctly,
>> bootstrapped compiler doesnt.
>
> I've seen this too, but it doesn't always seem to be
> related with argptr elimination.
>
> Look at this change between stage2/mkdeps.o and
> stage3/mkdeps.o:
>
>  00000000 <munge>:
>     0:  4e56 0000       linkw %fp,#0
>     4:  48e7 3020       moveml %d2-%d3/%a2,%sp@-
> -   8:  242e 0008       movel %fp@(8),%d2
> -   c:  2442            moveal %d2,%a2
> +   8:  246e 0008       moveal %fp@(8),%a2
> +   c:  240a            movel %a2,%d2
>     e:  91c8            subal %a0,%a0
>    10:  1012            moveb %a2@,%d0
>    12:  6718            beqs 2c <munge+0x2c>
>
> Both versions are fine, but I wonder why a different
> instruction pattern has been generated.

I see such spurious differences from time to time on ia64 as well.  It
looks like a generic problem.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Andreas Schwab wrote:

>>Look at this change between stage2/mkdeps.o and
>>stage3/mkdeps.o:
>>
>> 00000000 <munge>:
>>    0:  4e56 0000       linkw %fp,#0
>>    4:  48e7 3020       moveml %d2-%d3/%a2,%sp@-
>>-   8:  242e 0008       movel %fp@(8),%d2
>>-   c:  2442            moveal %d2,%a2
>>+   8:  246e 0008       moveal %fp@(8),%a2
>>+   c:  240a            movel %a2,%d2
>>    e:  91c8            subal %a0,%a0
>>   10:  1012            moveb %a2@,%d0
>>   12:  6718            beqs 2c <munge+0x2c>
>>
>>Both versions are fine, but I wonder why a different
>>instruction pattern has been generated.
> 
> I see such spurious differences from time to time on ia64 as well.  It
> looks like a generic problem.

You mean with a simple crosscompiler?  Then how shall we
interpret it?

I still can't compare intermediate dumps because my build
host is in the middle of another bootstrap :-(

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Andreas Schwab]

Bernardo Innocenti <bernie@develer.com> writes:

> Andreas Schwab wrote:
>
>>>Look at this change between stage2/mkdeps.o and
>>>stage3/mkdeps.o:
>>>
>>> 00000000 <munge>:
>>>    0:  4e56 0000       linkw %fp,#0
>>>    4:  48e7 3020       moveml %d2-%d3/%a2,%sp@-
>>>-   8:  242e 0008       movel %fp@(8),%d2
>>>-   c:  2442            moveal %d2,%a2
>>>+   8:  246e 0008       moveal %fp@(8),%a2
>>>+   c:  240a            movel %a2,%d2
>>>    e:  91c8            subal %a0,%a0
>>>   10:  1012            moveb %a2@,%d0
>>>   12:  6718            beqs 2c <munge+0x2c>
>>>
>>>Both versions are fine, but I wonder why a different
>>>instruction pattern has been generated.
>> I see such spurious differences from time to time on ia64 as well.  It
>> looks like a generic problem.
>
> You mean with a simple crosscompiler?

No, native.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Andreas Schwab wrote:
> Bernardo Innocenti <bernie@develer.com> writes:
>>Andreas Schwab wrote:
>>>>Look at this change between stage2/mkdeps.o and
>>>>stage3/mkdeps.o:
>>>>
>>>>00000000 <munge>:
>>>>   0:  4e56 0000       linkw %fp,#0
>>>>   4:  48e7 3020       moveml %d2-%d3/%a2,%sp@-
>>>>-   8:  242e 0008       movel %fp@(8),%d2
>>>>-   c:  2442            moveal %d2,%a2
>>>>+   8:  246e 0008       moveal %fp@(8),%a2
>>>>+   c:  240a            movel %a2,%d2
>>>>   e:  91c8            subal %a0,%a0
>>>>  10:  1012            moveb %a2@,%d0
>>>>  12:  6718            beqs 2c <munge+0x2c>
>>>>
>>>>Both versions are fine, but I wonder why a different
>>>>instruction pattern has been generated.
>>>
>>>I see such spurious differences from time to time on ia64 as well.  It
>>>looks like a generic problem.
>>
>>You mean with a simple crosscompiler?
> 
> No, native.

I'm confused: you do get differences between different
builds builds of gcc compiled from the same source tree?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Andreas Schwab]

Bernardo Innocenti <bernie@develer.com> writes:

> I'm confused: you do get differences between different
> builds builds of gcc compiled from the same source tree?

I sometimes get bootstrap failures on ia64, and the one and only
difference between stage2 and stage3 is two insns being swapped in a
single object file without any semantic change.  Those failures go away
when changing the environment in any way, and because of that I was unable
to debug that yet.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Jim Wilson]

Andreas Schwab wrote:
> I sometimes get bootstrap failures on ia64, and the one and only
> difference between stage2 and stage3 is two insns being swapped in a
> single object file without any semantic change.  Those failures go away
> when changing the environment in any way, and because of that I was unable
> to debug that yet.

There is a known problem with the scheduler's use of cselib.  This only 
happens on IA-64, because only IA-64 uses the sched-ebb.c file which 
enables use of cselib.

The problem is that the scheduler calls cselib, stores data returned 
from cselib in scheduler data structures, cselib frees the data when it 
doesn't need it anymore, and then the scheduler dereferences the 
already-freed data getting garbage.

There was a long discussion about this a few months ago, but it didn't 
come to any resolution.  It was either Jakub or Jan that tracked down 
the problem to the scheduler's use of cselib.  I think it was HJ that 
reported the initial bootstrapping bug.

I've never seen this problem on my machine.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: m68k bootstrapping broken

[Andreas Schwab]

Jim Wilson <wilson@specifixinc.com> writes:

> Andreas Schwab wrote:
>> I sometimes get bootstrap failures on ia64, and the one and only
>> difference between stage2 and stage3 is two insns being swapped in a
>> single object file without any semantic change.  Those failures go away
>> when changing the environment in any way, and because of that I was unable
>> to debug that yet.
>
> There is a known problem with the scheduler's use of cselib.  This only
> happens on IA-64, because only IA-64 uses the sched-ebb.c file which
> enables use of cselib.

Yes, I remember now.  I think the last time I saw it on the 3.3 branch.

Anyway, the comparison failures on m68k are obviously not connected to
this.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Jim Wilson]

Andreas Schwab wrote:
> I sometimes get bootstrap failures on ia64, and the one and only
> difference between stage2 and stage3 is two insns being swapped in a
> single object file without any semantic change.  Those failures go away
> when changing the environment in any way, and because of that I was unable
> to debug that yet.

There is a known problem with the scheduler's use of cselib.  This only 
happens on IA-64, because only IA-64 uses the sched-ebb.c file which 
enables use of cselib.

The problem is that the scheduler calls cselib, stores data returned 
from cselib in scheduler data structures, cselib frees the data when it 
doesn't need it anymore, and then the scheduler dereferences the 
already-freed data getting garbage.

There was a long discussion about this a few months ago, but it didn't 
come to any resolution.  It was either Jakub or Jan that tracked down 
the problem to the scheduler's use of cselib.  I think it was HJ that 
reported the initial bootstrapping bug.

I've never seen this problem on my machine.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: m68k bootstrapping broken

[Gunther Nikl]

On Sun, Jan 11, 2004 at 09:27:17PM +0100, Andreas Schwab wrote:
> Andreas Schwab <schwab@suse.de> writes:
> 
> > Richard Zidlicky <rz@linux-m68k.org> writes:
> >
> >> here is what the brute force search yields:
> >>
> >> - ICE on lshrdi occurs when insn-recog.o is crosscompiled with -O2
> >
> > I've found the bug: for all CONST_METHODs except MOVQ and MOVL we
> > don't generate a useful CC, but we don't record this fact.  Could you
> > please test this patch?
> 
> I checked again, SWAP will also produce a correct cc, here is an
> updated patch.

  I just built a native compiler for m68k-amigaos with a cross-compiler
  that had the updated patch applied. No objects in gcc/ except m68k.o
  differed. Is that a good or bad sign?
  Flags used to build the native compiler:
    CFLAGS=-O2
    XCFLAGS=-m68060 -fomit-frame-pointer -fno-reorder-blocks

  Gunther

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Gunther Nikl wrote:

>>I checked again, SWAP will also produce a correct cc, here is an
>>updated patch.
> 
>   I just built a native compiler for m68k-amigaos with a cross-compiler
>   that had the updated patch applied. No objects in gcc/ except m68k.o
>   differed. Is that a good or bad sign?

You mean "differed between your previous build and the build with
Andreas patch"?

Richard Zidlicky reported a difference in "make compare" which you
can't do unless you perform a full staged bootstrap with a native
compiler.

>   Flags used to build the native compiler:
>     CFLAGS=-O2
>     XCFLAGS=-m68060 -fomit-frame-pointer -fno-reorder-blocks

By the way, do you also agree that -fomit-frame-pointer is always
a win on m68k?  AFAIK, gdb handles it correctly and all
-fomit-frame-pointer bugs should have been fixed.

I'll run a testsuite with -fomit-frame-pointer enabled to make
sure it doesn't break anything.

My proposal is to switch m68k to imply -fomit-frame-pointer with
-O.  Of course, I think we're too late for 3.4, so it will have
to be postponed even if we all agree.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Tue, Jan 13, 2004 at 10:57:29PM +0100, Bernardo Innocenti wrote:
 
> By the way, do you also agree that -fomit-frame-pointer is always
> a win on m68k?  AFAIK, gdb handles it correctly and all
> -fomit-frame-pointer bugs should have been fixed.

I have gdb-6.0 here and dont see how it does work, although
I would be really glad if baktrace would work. Compiling stuff
with "-gdwarf-2 -g3" - am I missing something?

> My proposal is to switch m68k to imply -fomit-frame-pointer with
> -O.  Of course, I think we're too late for 3.4, so it will have
> to be postponed even if we all agree.

it would be -O2 if at all.

For m68k-linux it has the additional side effect of enforcing
a stricter interpretaion of our slightly unusual a0/d0/fp0 abi
so it wont be so good to have this as default.

Richard

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:

>>By the way, do you also agree that -fomit-frame-pointer is always
>>a win on m68k?  AFAIK, gdb handles it correctly and all
>>-fomit-frame-pointer bugs should have been fixed.
> 
> I have gdb-6.0 here and dont see how it does work, although
> I would be really glad if baktrace would work. Compiling stuff
> with "-gdwarf-2 -g3" - am I missing something?

I usually use -ggdb.  GDB 6.0 still has some problems with the
ColdFire BDM target, so I'm primarly using 5.3.  I vaguely recall
seeing correct backtraces in the uClinux kernel, which is compiled
by default with -fomit-frame-pointer.  But perhaps 


>>My proposal is to switch m68k to imply -fomit-frame-pointer with
>>-O.  Of course, I think we're too late for 3.4, so it will have
>>to be postponed even if we all agree.
> 
> it would be -O2 if at all.

fp elimination is a trivial optimization that adds very little
compile-time impact and doesn't affect code layout, so it's
enabled at -O1:

     `-O' also turns on `-fomit-frame-pointer' on machines where doing
     so does not interfere with debugging.


> For m68k-linux it has the additional side effect of enforcing
> a stricter interpretaion of our slightly unusual a0/d0/fp0 abi
> so it wont be so good to have this as default.

I don't understand why the fp should interact with
the way you store return values in registers...

Anyway, if it's problematic for m68k-linux we could
enable it on selected OS targets instead of doing
it globally.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Wed, Jan 14, 2004 at 12:33:55AM +0100, Bernardo Innocenti wrote:
 
> I usually use -ggdb.  GDB 6.0 still has some problems with the
> ColdFire BDM target, so I'm primarly using 5.3.  I vaguely recall
> seeing correct backtraces in the uClinux kernel, which is compiled
> by default with -fomit-frame-pointer.  But perhaps 

linux kernel is a special case, do you use gdb to debug it?
Code compiled with -ggdb definitely does not have correct
baktrace here.

>     `-O' also turns on `-fomit-frame-pointer' on machines where doing
>     so does not interfere with debugging.

well afaics it does heavilly interfere with debugging on m68k.

Richard

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:
> On Wed, Jan 14, 2004 at 12:33:55AM +0100, Bernardo Innocenti wrote:
>  
> 
>>I usually use -ggdb.  GDB 6.0 still has some problems with the
>>ColdFire BDM target, so I'm primarly using 5.3.  I vaguely recall
>>seeing correct backtraces in the uClinux kernel, which is compiled
>>by default with -fomit-frame-pointer.  But perhaps 
> 
> 
> linux kernel is a special case, do you use gdb to debug it?

Yes, I do: I connect to my target board with a BDM pod.  GDB can
load the kernel image in RAM and debug it.  Even in interrupts! ;-)

> Code compiled with -ggdb definitely does not have correct
> baktrace here.

I'll retest.  What specific gdb version were you using again?
I'm mostly using gdb 5.3 targeted at m68k-elf (well, actually
it's m68k-bdm-elf).  I gave 6.0 a shot but I had several problems.

>>    `-O' also turns on `-fomit-frame-pointer' on machines where doing
>>    so does not interfere with debugging.
> 
> well afaics it does heavilly interfere with debugging on m68k.

If so, we shouldn't enable it, at least not for m68k-linux.  It's
most probably a bug or limitation in gdb, because the dwarf2 debug
info should be enough to do backtraces and inspect variables in the
frame.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Thu, Jan 15, 2004 at 12:53:15AM +0100, Bernardo Innocenti wrote:

> I'll retest.  What specific gdb version were you using again?
> I'm mostly using gdb 5.3 targeted at m68k-elf (well, actually
> it's m68k-bdm-elf).  I gave 6.0 a shot but I had several problems.

anything from 4.17 to 6.0 does not give correct backtrace for
c programs with fomit-frame-pointer. 

Strangely, it appaears backtrace for c++ programs works even
despite fomit-frame-pointer? How can that work? I tried every
option I could spot, funwind-tables, ggdb, gdwarf etc.

Richard

Re: m68k bootstrapping broken

[Andreas Schwab]

Richard Zidlicky <rz@linux-m68k.org> writes:

> On Thu, Jan 15, 2004 at 12:53:15AM +0100, Bernardo Innocenti wrote:
>
>> I'll retest.  What specific gdb version were you using again?
>> I'm mostly using gdb 5.3 targeted at m68k-elf (well, actually
>> it's m68k-bdm-elf).  I gave 6.0 a shot but I had several problems.
>
> anything from 4.17 to 6.0 does not give correct backtrace for
> c programs with fomit-frame-pointer. 

No released version of gdb supports dwarf2 frame unwinding on m68k yet.
If you want to try out you need to apply this patch to gdb 6.0:

--- m68k-tdep.c.~1.69.4.2.~	2003-07-10 10:50:02.000000000 +0200
+++ m68k-tdep.c	2003-09-23 10:10:48.000000000 +0200
@@ -21,6 +21,7 @@
    Boston, MA 02111-1307, USA.  */
 
 #include "defs.h"
+#include "dwarf2-frame.h"
 #include "frame.h"
 #include "frame-base.h"
 #include "frame-unwind.h"
@@ -1151,6 +1152,11 @@ m68k_gdbarch_init (struct gdbarch_info i
   /* Frame unwinder.  */
   set_gdbarch_unwind_dummy_id (gdbarch, m68k_unwind_dummy_id);
   set_gdbarch_unwind_pc (gdbarch, m68k_unwind_pc);
+
+  /* Hook in the DWARF CFI frame unwinder.  */
+  frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer);
+  set_gdbarch_dwarf2_build_frame_info (gdbarch, dwarf2_build_frame_info);
+
   frame_base_set_default (gdbarch, &m68k_frame_base);
 
   /* Hook in ABI-specific overrides, if they have been registered.  */

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Thu, Jan 15, 2004 at 02:58:35PM +0100, Andreas Schwab wrote:

Hi,

> --- m68k-tdep.c.~1.69.4.2.~	2003-07-10 10:50:02.000000000 +0200
> +++ m68k-tdep.c	2003-09-23 10:10:48.000000000 +0200

works perfectly on simple programs compiled with debugging
info. 

With a complex program I tried sometimes it works, sometimes 
within the same program) it appears gdb for some reason falls
back to the old guessing algorithm and I get garbage like this:

Program received signal SIGINT, Interrupt.
0xc0121986 in __sigsuspend (set=0xeffff744)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:71
71      ../sysdeps/unix/sysv/linux/sigsuspend.c: No such file or directory.
        in ../sysdeps/unix/sysv/linux/sigsuspend.c
(gdb) bt
#0  0xc0121986 in __sigsuspend (set=0xeffff744)
    at ../sysdeps/unix/sysv/linux/sigsuspend.c:71
#1  0x8002a1f0 in SchedulerCmd () at xqlmouse.c:507
#2  0x00000008 in ?? ()
#3  0x00000001 in ?? ()
#4  0x80084f28 in ?? ()
#5  0x80084f28 in ?? ()
#6  0x8001bfea in PutToEA_l_m7 (r=-4, d=0) at iexl_general.c:1260
#7  0xeffff934 in ?? ()
#8  0x80024af2 in ExecuteLoop () at instructions_pz.c:268
#9  0xeffff8d8 in ?? ()
#10 0xeffff910 in ?? ()
#11 0x80029a0e in main (ac=0, av=0x0) at xlmain.c:62

Seems like everything is ok as long as all functions are in the same
object file and goes wrong if it has to backtrace to some function in
another module. 

Sometimes gdb-6.0 segfaults like this:

#0  0x800fd560 in dwarf2_frame_find_fde ()
(gdb) bt
#0  0x800fd560 in dwarf2_frame_find_fde ()
#1  0x00000001 in ?? ()
#2  0x8020d7e8 in ?? ()
#3  0x80211b38 in ?? ()
#4  0x800fd7e6 in dwarf2_frame_sniffer ()
#5  0x800bda84 in frame_unwind_find_by_frame ()
#6  0x8100a100 in ?? ()
#7  0xffffffff in ?? ()
#8  0x8100a150 in ?? ()
#9  0x8100a150 in ?? ()
#10 0x00000001 in ?? ()
#11 0x800bb1a4 in get_frame_type ()

... I wish I had compiled it with debugging info enabled but
it will take another few hours to get better info :(

Richard

Re: m68k bootstrapping broken

[Daniel Jacobowitz]

On Thu, Jan 15, 2004 at 11:57:28PM +0100, Richard Zidlicky wrote:
> Sometimes gdb-6.0 segfaults like this:
> 
> #0  0x800fd560 in dwarf2_frame_find_fde ()
> (gdb) bt
> #0  0x800fd560 in dwarf2_frame_find_fde ()
> #1  0x00000001 in ?? ()
> #2  0x8020d7e8 in ?? ()
> #3  0x80211b38 in ?? ()
> #4  0x800fd7e6 in dwarf2_frame_sniffer ()
> #5  0x800bda84 in frame_unwind_find_by_frame ()
> #6  0x8100a100 in ?? ()
> #7  0xffffffff in ?? ()
> #8  0x8100a150 in ?? ()
> #9  0x8100a150 in ?? ()
> #10 0x00000001 in ?? ()
> #11 0x800bb1a4 in get_frame_type ()
> 
> ... I wish I had compiled it with debugging info enabled but
> it will take another few hours to get better info :(

If this is after rebuilding/reloading the application, try GDB CVS
instead.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Thu, Jan 15, 2004 at 02:58:35PM +0100, Andreas Schwab wrote:
> Richard Zidlicky <rz@linux-m68k.org> writes:
> 
> > On Thu, Jan 15, 2004 at 12:53:15AM +0100, Bernardo Innocenti wrote:
> >
> >> I'll retest.  What specific gdb version were you using again?
> >> I'm mostly using gdb 5.3 targeted at m68k-elf (well, actually
> >> it's m68k-bdm-elf).  I gave 6.0 a shot but I had several problems.
> >
> > anything from 4.17 to 6.0 does not give correct backtrace for
> > c programs with fomit-frame-pointer. 
> 
> No released version of gdb supports dwarf2 frame unwinding on m68k yet.
> If you want to try out you need to apply this patch to gdb 6.0:
> 
> --- m68k-tdep.c.~1.69.4.2.~	2003-07-10 10:50:02.000000000 +0200
> +++ m68k-tdep.c	2003-09-23 10:10:48.000000000 +0200

building right now, requires #include "symfile.h" as well.

Richard

@@ -33,7 +34,7 @@
 #include "regcache.h"
 #include "arch-utils.h"
 #include "osabi.h"
-
+#include "symfile.h"
 #include "m68k-tdep.h"

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:

>>I'll retest.  What specific gdb version were you using again?
>>I'm mostly using gdb 5.3 targeted at m68k-elf (well, actually
>>it's m68k-bdm-elf).  I gave 6.0 a shot but I had several problems.
> 
> anything from 4.17 to 6.0 does not give correct backtrace for
> c programs with fomit-frame-pointer. 

Perhaps it's a regression on mainline... I've not yet been able
to test.


> Strangely, it appaears backtrace for c++ programs works even
> despite fomit-frame-pointer? How can that work? I tried every
> option I could spot, funwind-tables, ggdb, gdwarf etc.

Hmmm... perhaps exception handling is forcing functions to use
fp despite the -fo-f-p flag.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Gunther Nikl]

On Tue, Jan 13, 2004 at 10:57:29PM +0100, Bernardo Innocenti wrote:
> Gunther Nikl wrote:
> 
> >>I checked again, SWAP will also produce a correct cc, here is an
> >>updated patch.
> >
> >  I just built a native compiler for m68k-amigaos with a cross-compiler
> >  that had the updated patch applied. No objects in gcc/ except m68k.o
> >  differed. Is that a good or bad sign?
> 
> You mean "differed between your previous build and the build with
> Andreas patch"?

  Yes. I don't do native bootstraps because I don't have enough time and
  patience for them ;)

> Richard Zidlicky reported a difference in "make compare" which you
> can't do unless you perform a full staged bootstrap with a native
> compiler.

  IMHO, if there is a bug with CC handling it _should_ also be visible
  with a cross-compiler, shouldn't it? If GCC(cc1) generates wrong code
  then there must be a change in the cc1 executable (besides the patch
  place!). Maybe I am wrong about it but the CC problem I ran into
  was observable with a cross-compiler and the generated code after
  the fix was different compared to the code before the fix. That doesn't
  seem to be the case with the output_move_const_into_data_reg() patch.

> >  Flags used to build the native compiler:
> >    CFLAGS=-O2
> >    XCFLAGS=-m68060 -fomit-frame-pointer -fno-reorder-blocks
> 
> By the way, do you also agree that -fomit-frame-pointer is always
> a win on m68k?

  Code size decreases and one more spare register. I have always used
  -fomit-frame-pointer. I have no timings what it really buys.

> AFAIK, gdb handles it correctly and all -fomit-frame-pointer bugs should
> have been fixed.
>
> I'll run a testsuite with -fomit-frame-pointer enabled to make
> sure it doesn't break anything.
> 
> My proposal is to switch m68k to imply -fomit-frame-pointer with
> -O.  Of course, I think we're too late for 3.4, so it will have
> to be postponed even if we all agree.

  Enabling -fomit-frame-pointer by default with -O would be OK with me.

  Gunther

Re: m68k bootstrapping broken

[Andreas Schwab]

Gunther Nikl <gni@gecko.de> writes:

>   IMHO, if there is a bug with CC handling it _should_ also be visible
>   with a cross-compiler, shouldn't it? If GCC(cc1) generates wrong code
>   then there must be a change in the cc1 executable (besides the patch
>   place!). Maybe I am wrong about it but the CC problem I ran into
>   was observable with a cross-compiler and the generated code after
>   the fix was different compared to the code before the fix. That doesn't
>   seem to be the case with the output_move_const_into_data_reg() patch.

What did you test exactly?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Gunther Nikl]

On Wed, Jan 14, 2004 at 05:14:05PM +0100, Andreas Schwab wrote:
> Gunther Nikl <gni@gecko.de> writes:
> 
> >   IMHO, if there is a bug with CC handling it _should_ also be visible
> >   with a cross-compiler, shouldn't it? If GCC(cc1) generates wrong code
> >   then there must be a change in the cc1 executable (besides the patch
> >   place!). Maybe I am wrong about it but the CC problem I ran into
> >   was observable with a cross-compiler and the generated code after
> >   the fix was different compared to the code before the fix. That doesn't
> >   seem to be the case with the output_move_const_into_data_reg() patch.
> 
> What did you test exactly?

  [First, I noticed that it was stated the bug does only show up on a native
   bootstrap. However, you also stated you had a miscompiled compiler created
   by a ppc->m68k cross-compiler.]

  I used a checkout from 12.1.2004. I built a i386->m68k cross compiler
  for m68k-amigaos and then used this cross-compiler to built a native
  compiler for m68k-amigaos. Then I installed your patch to
  m68k.c/output_move_const_into_data_reg and created a new cross-compiler.
  This cross-compiler was then used to compile a new native compiler.
  Then I compared the objects in gcc/ for the native compiler versions
  created by the unpatched and patched cross-compilers. There was no
  difference except in m68k.o/output_move_const_into_data_reg (because
  of your patch). IMHO, there _should_ be differences in other objects if
  your patch would really fix a miscompilation. If there is no difference
  then your patch doesn't have any effect, does it?

  Maybe I am totally off-track with my reasoning.

  Gunther

Re: m68k bootstrapping broken

[Andreas Schwab]

Gunther Nikl <gni@gecko.de> writes:

>   If there is no difference then your patch doesn't have any effect,
>   does it?

It should have an effect, but you first have to verify that the bug exists
in the first place.  The m68k-amigaos configuration may be different
enough from m68k-linux to hide the bug.  Although this was a long standing
bug, it didn't trigger until now during gcc bootstraps.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Gunther Nikl]

On Wed, Jan 14, 2004 at 06:12:21PM +0100, Andreas Schwab wrote:
> Gunther Nikl <gni@gecko.de> writes:
> 
> >   If there is no difference then your patch doesn't have any effect,
> >   does it?
> 
> It should have an effect, but you first have to verify that the bug exists
> in the first place.  The m68k-amigaos configuration may be different
> enough from m68k-linux to hide the bug.  Although this was a long standing
> bug, it didn't trigger until now during gcc bootstraps.

  A small testcase showing the bug would be helpful. Compiling GCC isn't
  fun on a slow machine.
  I find it hard to believe that this bug does only surface by native
  bootstrap because your patch modifies a central m68k.c place.

  Gunther

Re: m68k bootstrapping broken

[Andreas Schwab]

Gunther Nikl <gni@gecko.de> writes:

> On Wed, Jan 14, 2004 at 06:12:21PM +0100, Andreas Schwab wrote:
>> Gunther Nikl <gni@gecko.de> writes:
>> 
>> >   If there is no difference then your patch doesn't have any effect,
>> >   does it?
>> 
>> It should have an effect, but you first have to verify that the bug exists
>> in the first place.  The m68k-amigaos configuration may be different
>> enough from m68k-linux to hide the bug.  Although this was a long standing
>> bug, it didn't trigger until now during gcc bootstraps.
>
>   A small testcase showing the bug would be helpful.

This is very difficult to create.  The problem on m68k-linux showed in
insn-recog.o where in a few places a "tst.l %dN" was missing after the
load of a constant handled by output_move_const_into_data_reg.  It only
showed up because -funit-at-a-time (implied by -O2) managed to inline
recog_3 into recog_7.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Joe Buck]

On Wed, Jan 14, 2004 at 06:23:48PM +0100, Gunther Nikl wrote:
> > It should have an effect, but you first have to verify that the bug exists
> > in the first place.  The m68k-amigaos configuration may be different
> > enough from m68k-linux to hide the bug.  Although this was a long standing
> > bug, it didn't trigger until now during gcc bootstraps.
> 
>   A small testcase showing the bug would be helpful. Compiling GCC isn't
>   fun on a slow machine.
>   I find it hard to believe that this bug does only surface by native
>   bootstrap because your patch modifies a central m68k.c place.

With a native bootstrap, the compiler itself is always the first test case
run; this test case is usually avoided when cross-compiling.
 

Re: m68k bootstrapping broken

[Richard Zidlicky]

Hi,

I have now another problem, gcc-3.4-20040107 goes into infinite
recrusion when compiling cp-demangle.c from binutils-2.14.90.0.6.

Happens with the crosscompiler and does not appear to be related
to the latest m68k fixes. gcc-3.4-20031210 didnt do this
- does this look like any known problem?


Richard


#0  0x081cafa6 in create_edge (caller=0x403b58dc, callee=0x403a3288)
    at ../../gcc-3.4-20040107/gcc/cgraph.c:171
#1  0x081cbd80 in record_call_1 (tp=0x43b4b2c4, walk_subtrees=0xbff9d798, 
    data=0x403ad06c) at ../../gcc-3.4-20040107/gcc/cgraphunit.c:261
#2  0x081ca53c in walk_tree (tp=0x43b4b2c4, func=0x81cbcb4 <record_call_1>, 
    data=0x403ad06c, htab_=0x83b0980)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1747
#3  0x081ca830 in walk_tree (tp=0x43b4ca28, func=0x81cbcb4 <record_call_1>, 
    data=0x403ad06c, htab_=0x83b0980)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1811
#4  0x081ca8c1 in walk_tree (tp=0xbff9d844, func=0x81cbcb4 <record_call_1>, 
    data=0x403ad06c, htab_=0x83b0980)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#5  0x081cbdda in cgraph_create_edges (decl=0x403ad06c, body=0x43b4c8d4)
    at ../../gcc-3.4-20040107/gcc/cgraphunit.c:303
#6  0x081ca1a2 in expand_call_inline (tp=0x43b3a258, walk_subtrees=0xbff9d8a8, 
    data=0xbffff730) at ../../gcc-3.4-20040107/gcc/tree-inline.c:1573
#7  0x081ca53c in walk_tree (tp=0x43b3a258, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1747
#8  0x081ca830 in walk_tree (tp=0x43b3c30c, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1811
#9  0x081ca8c1 in walk_tree (tp=0x43b32ecc, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#10 0x081ca8c1 in walk_tree (tp=0x43b32db0, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#11 0x081ca8c1 in walk_tree (tp=0x43b18b94, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#12 0x081ca8c1 in walk_tree (tp=0x43b33d34, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#13 0x081ca8c1 in walk_tree (tp=0x43b18b74, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#14 0x081ca8c1 in walk_tree (tp=0x43b18a18, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#15 0x081ca8c1 in walk_tree (tp=0x43b3071c, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#16 0x081ca8c1 in walk_tree (tp=0x43b30550, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#17 0x081ca2ce in expand_calls_inline (tp=0x43b30550, id=0x42a97618)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1610
#18 0x081ca154 in expand_call_inline (tp=0x43b20f00, walk_subtrees=0xbff9daf8, 
    data=0xbffff730) at ../../gcc-3.4-20040107/gcc/tree-inline.c:1580
#19 0x081ca53c in walk_tree (tp=0x43b20f00, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1747
#20 0x081ca830 in walk_tree (tp=0x43b2d8c0, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1811
#21 0x081ca8c1 in walk_tree (tp=0x43b27b9c, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#22 0x081ca8c1 in walk_tree (tp=0x43b188f4, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#23 0x081ca8c1 in walk_tree (tp=0x43b2d500, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#24 0x081ca8c1 in walk_tree (tp=0x43b2cfb4, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#25 0x081ca2ce in expand_calls_inline (tp=0x43b2cfb4, id=0x42a97618)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1610
#26 0x081ca154 in expand_call_inline (tp=0x43b11dbc, walk_subtrees=0xbff9dc88, 
    data=0xbffff730) at ../../gcc-3.4-20040107/gcc/tree-inline.c:1580
#27 0x081ca53c in walk_tree (tp=0x43b11dbc, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1747
#28 0x081ca830 in walk_tree (tp=0x43b1da00, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1811
#29 0x081ca8c1 in walk_tree (tp=0x43b1a53c, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#30 0x081ca8c1 in walk_tree (tp=0x43b1a420, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#31 0x081ca8c1 in walk_tree (tp=0x43af3e94, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#32 0x081ca8c1 in walk_tree (tp=0x43b14438, 
    func=0x81c9dac <expand_call_inline>, data=0xbffff730, htab_=0x82de760)
    at ../../gcc-3.4-20040107/gcc/tree-inline.c:1795
#33 0x081ca8c1 in walk_tree (tp=0x43af3e74, 
...........
...........

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Richard Zidlicky wrote:

> I have now another problem, gcc-3.4-20040107 goes into infinite
> recrusion when compiling cp-demangle.c from binutils-2.14.90.0.6.
                                              ^^^^^^^^^^^^^^^^^^^^

I don't know the cause of your problem, but why arn't you using
binutils-2.14.90.0.7?  I ask because the latest versions includes
some ColdFire patches submitted by me.  Do they introduce some
m68k regressions perhaps?


> Happens with the crosscompiler and does not appear to be related
> to the latest m68k fixes. gcc-3.4-20031210 didnt do this
> - does this look like any known problem?

Not to me... GCC bootstraps fine on i386 and I've extensively
tested the m68k-uclinux compiler with real world code.

I'm currently running make bootstrap on m68k-netbsd...  Does
"make compare" report any difference now?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Andreas Schwab wrote:

> 2004-01-11  Andreas Schwab  <schwab@suse.de>
> 
> 	* config/m68k/m68k.c (output_move_const_into_data_reg): Clear cc
> 	status for NOTB/NOTW/NEGW methods.

Andreas, I confirm this patch fixed the reported bootstrap ICE on
m68k-netbsdelf too.

The BSD box is now re-running the testsuite just in case.
Meanwhile, I rekon your patch should be committed.

Gaby, this bug was also present on 3.3.  It's apparently latent,
but potentially very dangerous (generates subtly wrong code for
conditional expressions).  Can we backport the patch?

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Richard Henderson]

On Thu, Jan 15, 2004 at 03:37:57AM +0100, Bernardo Innocenti wrote:
> Meanwhile, I rekon your patch should be committed.

Certainly.


r~

Re: m68k bootstrapping broken

[Andreas Schwab]

Bernardo Innocenti <bernie@develer.com> writes:

> Andreas Schwab wrote:
>
>> 2004-01-11  Andreas Schwab  <schwab@suse.de>
>> 	* config/m68k/m68k.c (output_move_const_into_data_reg): Clear cc
>> 	status for NOTB/NOTW/NEGW methods.
>
> Andreas, I confirm this patch fixed the reported bootstrap ICE on
> m68k-netbsdelf too.

Thanks for testing, I've committed it now.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Matthias Klose]

Andreas Schwab writes:
> Bernardo Innocenti <bernie@develer.com> writes:
> 
> > Andreas Schwab wrote:
> >
> >> 2004-01-11  Andreas Schwab  <schwab@suse.de>
> >> 	* config/m68k/m68k.c (output_move_const_into_data_reg): Clear cc
> >> 	status for NOTB/NOTW/NEGW methods.
> >
> > Andreas, I confirm this patch fixed the reported bootstrap ICE on
> > m68k-netbsdelf too.
> 
> Thanks for testing, I've committed it now.

For m68k-linux, I get until the bootstrap comparision with this
patch. The compare fails with (Andreas, files on scrub in ~doko/3.4)

Bootstrap comparison failure!
./alias.o differs
./alloc-pool.o differs
./attribs.o differs
./bb-reorder.o differs
./bitmap.o differs
./bt-load.o differs
./builtins.o differs
./c-aux-info.o differs
./c-common.o differs
./c-cppbuiltin.o differs
./c-decl.o differs
./c-dump.o differs
./c-errors.o differs
./c-format.o differs
./c-incpath.o differs
./c-lex.o differs
./c-objc-common.o differs
./c-opts.o differs
./c-parse.o differs
./c-pch.o differs
./c-ppoutput.o differs
./c-pragma.o differs
./c-pretty-print.o differs
./c-semantics.o differs
./c-typeck.o differs
./caller-save.o differs
./calls.o differs
./cfg.o differs
./cfganal.o differs
./cfgbuild.o differs
./cfgcleanup.o differs
./cfglayout.o differs
./cfgloop.o differs
./cfgloopanal.o differs
./cfgloopmanip.o differs
./cfgrtl.o differs
./cgraph.o differs
./cgraphunit.o differs
./collect2.o differs
./combine.o differs
./conflict.o differs
./convert.o differs
./coverage.o differs
./cppcharset.o differs
./cpperror.o differs
./cppexp.o differs
./cppfiles.o differs
./cpphash.o differs
./cppinit.o differs
./cpplex.o differs
./cpplib.o differs
./cppmacro.o differs
./cpppch.o differs
./cppspec.o differs
./cpptrad.o differs
./cse.o differs
./cselib.o differs
./dbxout.o differs
./df.o differs
./diagnostic.o differs
./dojump.o differs
./dominance.o differs
./dwarf2asm.o differs
./dwarf2out.o differs
./emit-rtl.o differs
./errors.o differs
./et-forest.o differs
./except.o differs
./explow.o differs
./expmed.o differs
./expr.o differs
./final.o differs
./flow.o differs
./fold-const.o differs
./function.o differs
./g++spec.o differs
./g77spec.o differs
./gcc.o differs
./gccspec.o differs
./gcov-dump.o differs
./gcov-iov.o differs
./gcov.o differs
./gcse.o differs
./genattr.o differs
./genattrtab.o differs
./genautomata.o differs
./gencodes.o differs
./genconditions.o differs
./genconfig.o differs
./genconstants.o differs
./genemit.o differs
./genextract.o differs
./genflags.o differs
./gengenrtl.o differs
./gengtype-lex.o differs
./gengtype.o differs
./genmodes.o differs
./genopinit.o differs
./genoutput.o differs
./genpeep.o differs
./genrecog.o differs
./genrtl.o differs
./gensupport.o differs
./ggc-common.o differs
./ggc-page.o differs
./global.o differs
./graph.o differs
./gtype-desc.o differs
./hashtable.o differs
./ifcvt.o differs
./insn-emit.o differs
./insn-output.o differs
./insn-recog.o differs
./integrate.o differs
./jump.o differs
./jvspec.o differs
./langhooks.o differs
./lcm.o differs
./line-map.o differs
./lists.o differs
./local-alloc.o differs
./loop-init.o differs
./loop-unroll.o differs
./loop-unswitch.o differs
./loop.o differs
./m68k.o differs
./mkdeps.o differs
./optabs.o differs
./opts.o differs
./params.o differs
./postreload.o differs
./predict.o differs
./prefix.o differs
./pretty-print.o differs
./print-rtl.o differs
./print-rtl1.o differs
./print-tree.o differs
./profile.o differs
./ra-build.o differs
./ra-colorize.o differs
./ra-debug.o differs
./ra-rewrite.o differs
./ra.o differs
./read-rtl.o differs
./real.o differs
./recog.o differs
./regclass.o differs
./regmove.o differs
./regrename.o differs
./reload.o differs
./reload1.o differs
./resource.o differs
./rtl-error.o differs
./rtl.o differs
./rtlanal.o differs
./sbitmap.o differs
./sched-deps.o differs
./sched-ebb.o differs
./sibcall.o differs
./simplify-rtx.o differs
./sreal.o differs
./stmt.o differs
./stor-layout.o differs
./stringpool.o differs
./timevar.o differs
./tlink.o differs
./toplev.o differs
./tracer.o differs
./tree-dump.o differs
./tree-inline.o differs
./tree-optimize.o differs
./tree.o differs
./unroll.o differs
./varasm.o differs
./varray.o differs
./web.o differs
cp/call.o differs
cp/class.o differs
cp/cp-lang.o differs
cp/cvt.o differs
cp/cxx-pretty-print.o differs
cp/decl.o differs
cp/decl2.o differs
cp/dump.o differs
cp/error.o differs
cp/except.o differs
cp/expr.o differs
cp/friend.o differs
cp/init.o differs
cp/lex.o differs
cp/mangle.o differs
cp/method.o differs
cp/name-lookup.o differs
cp/parser.o differs
cp/pt.o differs
cp/ptree.o differs
cp/repo.o differs
cp/rtti.o differs
cp/search.o differs
cp/semantics.o differs
cp/tree.o differs
cp/typeck.o differs
cp/typeck2.o differs
f/bad.o differs
f/bit.o differs
f/bld.o differs
f/com.o differs
f/data.o differs
f/equiv.o differs
f/expr.o differs
f/fini.o differs
f/global.o differs
f/implic.o differs
f/info.o differs
f/intrin.o differs
f/lab.o differs
f/lex.o differs
f/malloc.o differs
f/name.o differs
f/src.o differs
f/sta.o differs
f/stb.o differs
f/stc.o differs
f/std.o differs
f/ste.o differs
f/storag.o differs
f/sts.o differs
f/stt.o differs
f/symbol.o differs
f/target.o differs
f/top.o differs
f/type.o differs
f/where.o differs
java/boehm.o differs
java/buffer.o differs
java/builtins.o differs
java/check-init.o differs
java/class.o differs
java/constants.o differs
java/decl.o differs
java/except.o differs
java/expr.o differs
java/gjavah.o differs
java/java-tree-inline.o differs
java/jcf-depend.o differs
java/jcf-dump.o differs
java/jcf-io.o differs
java/jcf-parse.o differs
java/jcf-path.o differs
java/jcf-write.o differs
java/jv-scan.o differs
java/jvgenmain.o differs
java/lang.o differs
java/mangle.o differs
java/mangle_name.o differs
java/parse-scan.o differs
java/parse.o differs
java/resource.o differs
java/typeck.o differs
java/verify.o differs
java/xref.o differs
objc/objc-act.o differs
objc/objc-parse.o differs
treelang/lex.o differs
treelang/parse.o differs
treelang/tree1.o differs
treelang/treetree.o differs
make[3]: *** [gnucompare-lean] Error 1
make[3]: Leaving directory `/home/doko/3.4/gcc-snapshot-20040113/build/gcc'
make[2]: *** [bootstrap-lean] Error 2
make[2]: Leaving directory `/home/doko/3.4/gcc-snapshot-20040113/build'

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Thu, Jan 15, 2004 at 02:14:31PM +0100, Matthias Klose wrote:
> Andreas Schwab writes:
> > Bernardo Innocenti <bernie@develer.com> writes:
> > 
> > > Andreas Schwab wrote:
> > >
> > >> 2004-01-11  Andreas Schwab  <schwab@suse.de>
> > >> 	* config/m68k/m68k.c (output_move_const_into_data_reg): Clear cc
> > >> 	status for NOTB/NOTW/NEGW methods.
> > >
> > > Andreas, I confirm this patch fixed the reported bootstrap ICE on
> > > m68k-netbsdelf too.
> > 
> > Thanks for testing, I've committed it now.
> 
> For m68k-linux, I get until the bootstrap comparision with this
> patch. The compare fails with (Andreas, files on scrub in ~doko/3.4)
> 

..hm, part of that might be because you build c++ and the other languages
as well. But having diffs in  every file is suspicious.. is it some binutils
problem or did "tail -16c" stop working or something like that?

Richard

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Andreas Schwab wrote:
> Bernardo Innocenti <bernie@develer.com> writes:
>>Andreas Schwab wrote:
>>
>>
>>>2004-01-11  Andreas Schwab  <schwab@suse.de>
>>>	* config/m68k/m68k.c (output_move_const_into_data_reg): Clear cc
>>>	status for NOTB/NOTW/NEGW methods.
>>
>>Andreas, I confirm this patch fixed the reported bootstrap ICE on
>>m68k-netbsdelf too.
> 
> Thanks for testing, I've committed it now.

I've now completed the testsuite with your patch installed
and I'm sorry to report something very weird.

A considerable number of tests failed.  Several failures
appear to be caused by deficencies in the ancient binutils
2.11.2 used by NetBSD.

Comparing these results with the previous run (without your
patch installed) reveals lots of changes (see the diff below).
What's shocking is that, overall, the number of failures
actually *increased*!

I've not yet analyzed any of these failures because I want
to try bootstrapping again from a combined tree in order
to use GNU as/ld.

--- lilith-20040111-gcc.sum	2004-01-13 21:29:49.000000000 +0100
+++ lilith-20040115-gcc.sum	2004-01-15 21:33:41.000000000 +0100
@@ -1 +1 @@
-Test Run By bernie on Mon Jan 12 17:17:03 2004
+Test Run By bernie on Wed Jan 14 21:05:01 2004
@@ -393,2 +393 @@
-WARNING: program timed out.
-FAIL: gcc.c-torture/compile/20001226-1.c (test for excess errors)
+PASS: gcc.c-torture/compile/20001226-1.c (test for excess errors)
@@ -3391,6 +3390,6 @@
-PASS: gcc.c-torture/compile/init-1.c (test for excess errors)
-PASS: gcc.c-torture/compile/init-1.c (test for excess errors)
-PASS: gcc.c-torture/compile/init-1.c (test for excess errors)
-PASS: gcc.c-torture/compile/init-1.c (test for excess errors)
-PASS: gcc.c-torture/compile/init-1.c (test for excess errors)
-PASS: gcc.c-torture/compile/init-1.c (test for excess errors)
+FAIL: gcc.c-torture/compile/init-1.c (test for excess errors)
+FAIL: gcc.c-torture/compile/init-1.c (test for excess errors)
+FAIL: gcc.c-torture/compile/init-1.c (test for excess errors)
+FAIL: gcc.c-torture/compile/init-1.c (test for excess errors)
+FAIL: gcc.c-torture/compile/init-1.c (test for excess errors)
+FAIL: gcc.c-torture/compile/init-1.c (test for excess errors)
@@ -9676 +9675 @@
-PASS: gcc.c-torture/execute/980205.c execution,  -O3 -fomit-frame-pointer 
+FAIL: gcc.c-torture/execute/980205.c execution,  -O3 -fomit-frame-pointer 
@@ -12118 +12117 @@
-FAIL: gcc.c-torture/execute/nestfunc-6.c execution,  -O0 
+PASS: gcc.c-torture/execute/nestfunc-6.c execution,  -O0 
@@ -15285,2 +15284 @@
-WARNING: program timed out.
-FAIL: gcc.dg/compat/struct-by-value-10 c_compat_x_tst.o compile
+PASS: gcc.dg/compat/struct-by-value-10 c_compat_x_tst.o compile
@@ -15288,2 +15286,2 @@
-UNRESOLVED: gcc.dg/compat/struct-by-value-10 c_compat_x_tst.o-c_compat_y_tst.o link 
-UNRESOLVED: gcc.dg/compat/struct-by-value-10 c_compat_x_tst.o-c_compat_y_tst.o execute 
+PASS: gcc.dg/compat/struct-by-value-10 c_compat_x_tst.o-c_compat_y_tst.o link
+PASS: gcc.dg/compat/struct-by-value-10 c_compat_x_tst.o-c_compat_y_tst.o execute 
@@ -17973,2 +17971,2 @@
-PASS: gcc.dg/c99-complit-1.c (test for excess errors)
-PASS: gcc.dg/c99-complit-1.c execution test
+FAIL: gcc.dg/c99-complit-1.c (test for excess errors)
+WARNING: gcc.dg/c99-complit-1.c compilation failed to produce executable
@@ -17994 +17992 @@
-PASS: gcc.dg/c99-complit-2.c non-const (test for errors, line 42)
+FAIL: gcc.dg/c99-complit-2.c non-const (test for errors, line 42)
@@ -18125,2 +18123 @@
-WARNING: program timed out.
-FAIL: gcc.dg/c99-intconst-1.c (test for excess errors)
+PASS: gcc.dg/c99-intconst-1.c (test for excess errors)
@@ -18672 +18669 @@
-PASS: gcc.dg/noreturn-7.c  (test for warnings, line 21)
+FAIL: gcc.dg/noreturn-7.c  (test for warnings, line 21)
@@ -18825 +18822 @@
-PASS: gcc.dg/sibcall-1.c execution test
+FAIL: gcc.dg/sibcall-1.c execution test
@@ -18827 +18824 @@
-PASS: gcc.dg/sibcall-2.c execution test
+FAIL: gcc.dg/sibcall-2.c execution test
@@ -18829 +18826 @@
-XPASS: gcc.dg/sibcall-3.c execution test
+XFAIL: gcc.dg/sibcall-3.c execution test
@@ -18831 +18828 @@
-XPASS: gcc.dg/sibcall-4.c execution test
+XFAIL: gcc.dg/sibcall-4.c execution test
@@ -24311,5 +24308,4 @@
-# of expected passes		23704
-# of unexpected failures	164
-# of unexpected successes	2
-# of expected failures		68
-# of unresolved testcases	3
+# of expected passes		23697
+# of unexpected failures	172
+# of expected failures		70
+# of unresolved testcases	1




-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Gunther Nikl]

On Sun, Jan 11, 2004 at 07:32:54AM +0100, Bernardo Innocenti wrote:
> Just an idea: m68k is the only cc0 target capable of an hosted bootstrap.

  I wonder how hard it would be to change m68k into a non-cc0 port.

> Is it possible that middle-end changes have subtly broken cc0 targets
> without anyone noticing except on the m68k?

  Its surprising that suddenly CC bugs show up. This is already the
  second time that not initializing CC is the reason for breakage of
  m68k.

  Gunther

Re: m68k bootstrapping broken

[Andreas Schwab]

Gunther Nikl <gni@gecko.de> writes:

> On Sun, Jan 11, 2004 at 07:32:54AM +0100, Bernardo Innocenti wrote:
>> Just an idea: m68k is the only cc0 target capable of an hosted bootstrap.
>
>   I wonder how hard it would be to change m68k into a non-cc0 port.

What would be the advantage in general?

>> Is it possible that middle-end changes have subtly broken cc0 targets
>> without anyone noticing except on the m68k?
>
>   Its surprising that suddenly CC bugs show up. This is already the
>   second time that not initializing CC is the reason for breakage of
>   m68k.

Due to unit-at-a-time there are more opportunities for optimisation.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Gunther Nikl]

On Tue, Jan 13, 2004 at 01:07:33PM +0100, Andreas Schwab wrote:
> Gunther Nikl <gni@gecko.de> writes:
> 
> > On Sun, Jan 11, 2004 at 07:32:54AM +0100, Bernardo Innocenti wrote:
> >> Just an idea: m68k is the only cc0 target capable of an hosted bootstrap.
> >
> >   I wonder how hard it would be to change m68k into a non-cc0 port.
> 
> What would be the advantage in general?

  No CC bugs? :) Wasn't ix86 before GCC 3.x a CC port?
  AFAICT, there is no primary cc0 port anymore and thus cc0 ports don't
  get much testing. Thus errors only affecting such ports will stay
  (almost) unnoticed.

  Gunther

Re: m68k bootstrapping broken

[Bernardo Innocenti]

Gunther Nikl wrote:
> On Sun, Jan 11, 2004 at 07:32:54AM +0100, Bernardo Innocenti wrote:
> 
>>Just an idea: m68k is the only cc0 target capable of an hosted bootstrap.
> 
>   I wonder how hard it would be to change m68k into a non-cc0 port.

I'm not sure what the benefits/disadvantages of cc0/non-cc0 targets
are... Is there any documentation on this topic or shall I dig in
the mailing list archives?


>>Is it possible that middle-end changes have subtly broken cc0 targets
>>without anyone noticing except on the m68k?
> 
>   Its surprising that suddenly CC bugs show up. This is already the
>   second time that not initializing CC is the reason for breakage of
>   m68k.

Yeah.  We also have intermittent bugs due to insn constraints not
covering all possible uses.  It keeps appearing in random versions
of GCC and with random combinations of options affecting code
generation.

After years of stratification the m68k backend has finally been
cleaned up, at least superficially (i.e.: the code is now
readable ;-).

The next step would be incrementally switching old stuff to
modern GCC design practices.  There was a discussion some time
ago about adding insn patterns for movem and use rtx function
prologues and epilogues instead of the current mess.


By the way, for anyone interested I've just posted the testsuite
results for m68k-netbsdelf:

   http://gcc.gnu.org/ml/gcc-testresults/2004-01/msg00543.html


I'm going to run the testsuite again with Andreas' latest patch,
and I'll soon be able to do regression testing on m68k-linux
thanks to the kind support from the debian-m68k people.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: m68k bootstrapping broken

[Gunther Nikl]

On Tue, Jan 13, 2004 at 10:34:37PM +0100, Bernardo Innocenti wrote:
> Gunther Nikl wrote:
> >On Sun, Jan 11, 2004 at 07:32:54AM +0100, Bernardo Innocenti wrote:
> >
> >>Just an idea: m68k is the only cc0 target capable of an hosted bootstrap.
> >
> >  I wonder how hard it would be to change m68k into a non-cc0 port.
> 
> I'm not sure what the benefits/disadvantages of cc0/non-cc0 targets
> are... Is there any documentation on this topic or shall I dig in
> the mailing list archives?

  Since all primary targets are non-cc0 targets, cc0 targets receive
  little (none?) testing and thus bugs affecting only cc0 targets are
  not discovered.

> The next step would be incrementally switching old stuff to
> modern GCC design practices.  There was a discussion some time
> ago about adding insn patterns for movem and use rtx function
> prologues and epilogues instead of the current mess.

  I remember the rtx for prologue/epilogue.

  Gunther

Re: m68k bootstrapping broken

[Richard Zidlicky]

On Sat, Jan 10, 2004 at 10:08:54PM +0100, Bernardo Innocenti wrote:
> Richard Zidlicky wrote:
> 
> >>No, it shouldn't be possible.  There might some obscure bug somewhere
> >>in corner cases such as functions with big frames or functions with
> >>strange attributes...
> >
> >even if it doesnt bomb it generates code like this:
> >__cmpdi2:
> >.LFB38:
> >	.file 1 "../../gcc-3.4-20031210/gcc/libgcc2.c"
> >	.loc 1 1068 0
> >	pea (%a6)
> >	move.l %sp,%a6
> 
> This is equivalent to:
> 
> 	link #0,a6
> 
> It's done only with -m68040 because it's faster.
> 
> >.LCFI0:
> >	move.l %d2,-(%sp)
> >.LCFI1:
> >	lea (8,%a6),%a0      !!!!!!!!
> >	move.l (%a0),%d0
> >	move.l 4(%a0),%d1
> >.....
> >
> >The use of %a0 is not incorrect but completely unnecessary.. same
> >optimisation settings etc again. What would cause this kind of code
> >get generated? Wrong cost estimate? Some comparison against +/32K
> >run amuck?
> 
> I believe this is how GCC has always worked.  Unless you specify
> -fomit-frame-pointer, a6 will be loaded with sp in function
> prologue, even if the frame size is 0.  This is done because older
> debuggers relied on it in order to find local variables.

nope, I meant the line marked by "!!!!!".. meanwhile I figured out
that argpointer elimination must have failed in that example. This
happens only during native compilation so you cant reproduce it for
now :(

Richard

Re: m68k bootstrapping broken

[Andreas Schwab]

Richard Zidlicky <rz@linux-m68k.org> writes:

> nope, I meant the line marked by "!!!!!".. meanwhile I figured out
> that argpointer elimination must have failed in that example. This
> happens only during native compilation so you cant reproduce it for
> now :(

I get this also with my ppc->m68k cross compiler.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k bootstrapping broken

[Hans-Peter Nilsson]

On Sun, 4 Jan 2004, Richard Zidlicky wrote:
>
> When I compile libgcc with the same flags with a crosscompiler this
> doesnt happen so it appears the compiler has miscompiled itself
> somewhere else.. anyone else seen this?

Not around 2003-12-10 for other targets.  In cases like this, it
has been suggested to simplify miscompilation analyzis by just
running "make all" instead of "make bootstrap" and then
investigate failures in "make check".  But this is mostly for
the archive, you probably already knew that...

brgds, H-P