Re: GCC 3.0.3 Prelease problem on --target=m68k-elf

Re: GCC 3.0.3 Prelease problem on --target=m68k-elf

[Peter Barada]

gcc-3.0.3-20011213 builds with the following config.status:
#!/bin/sh
# This file was generated automatically by configure.  Do not edit.
# This directory was configured as follows:
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.0.3-20011213/configure --with-gcc-version-trigger=/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.0.3-20011213/gcc/version.c --host=i686-pc-linux-gnu --target=m68k-elf --prefix=/tmp/crap5 --enable-languages=c --with-local-prefix=/tmp/crap5/m68k-elf --without-headers --with-newlib --disable-shared --norecursion 
# 

Unfortunately it doesn't produce correct code for -m5200 due to the
"r" constraint in the following pattern in gcc/config/m68k/m68k.md:

;; Jump to variable address from dispatch table of relative addresses.
(define_insn ""
  [(set (pc)
	(plus:SI (pc)
		 (sign_extend:SI (match_operand:HI 0 "register_operand" "r"))))
   (use (label_ref (match_operand 1 "" "")))]
  ""

On Coldfire the ext.l instruction can only extend data registers, not
address registers, so either the constraint needs to be changed to
"d", or another pettern needs to be created for TARGET_5200 with a "d"
constraint, and this needs a condition of !TARGET_5200.

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

Re: GCC 3.0.3 Prelease problem on --target=m68k-elf

[Joe Buck]

Peter Barada writes:
> gcc-3.0.3-20011213 builds with the following config.status:
> #!/bin/sh
> # This file was generated automatically by configure.  Do not edit.
> # This directory was configured as follows:
> /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.0.3-20011213/configure --with-gcc-version-trigger=/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.0.3-20011213/gcc/version.c --host=i686-pc-linux-gnu --target=m68k-elf --prefix=/tmp/crap5 --enable-languages=c --with-local-prefix=/tmp/crap5/m68k-elf --without-headers --with-newlib --disable-shared --norecursion 
> # 

> Unfortunately it doesn't produce correct code for -m5200 due to the
> "r" constraint in the following pattern in gcc/config/m68k/m68k.md:
> 
> ;; Jump to variable address from dispatch table of relative addresses.
> (define_insn ""
>   [(set (pc)
> 	(plus:SI (pc)
> 		 (sign_extend:SI (match_operand:HI 0 "register_operand" "r"))))
>    (use (label_ref (match_operand 1 "" "")))]
>   ""

Is this a regression with respect to 3.0.2, or 2.95.3?

Either way, it seems the thing to do is to file a bug report with GNATS
including a test case for which bad code generation occurs.

Re: GCC 3.0.3 Prelease problem on --target=m68k-elf

[Peter Barada]

>> Unfortunately it doesn't produce correct code for -m5200 due to the
>> "r" constraint in the following pattern in gcc/config/m68k/m68k.md:
>> 
>> ;; Jump to variable address from dispatch table of relative addresses.
>> (define_insn ""
>>   [(set (pc)
>> 	(plus:SI (pc)
>> 		 (sign_extend:SI (match_operand:HI 0 "register_operand" "r"))))
>>    (use (label_ref (match_operand 1 "" "")))]
>>   ""

>Is this a regression with respect to 3.0.2, or 2.95.3?

Its a regression from 2.95.3, the same problem is in 3.0.2.

>Either way, it seems the thing to do is to file a bug report with GNATS
>including a test case for which bad code generation occurs.

Ok, how do I file a bug report with GNATS?  I'll have to cobble
together a test case, but from inspection its obvious that the
constraint is wrong.

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

Re: GCC 3.0.3 Prelease problem on --target=m68k-elf

[Craig Rodrigues]

On Fri, Dec 14, 2001 at 10:27:48AM -0500, Peter Barada wrote:
> Ok, how do I file a bug report with GNATS?  I'll have to cobble
> together a test case, but from inspection its obvious that the
> constraint is wrong.

See: http://gcc.gnu.org/bugs.html for problem report
 posting instructions.

Before posting the bug report, you may want to see if your
bug is the same as:
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=5099&database=gcc
(login: guest, password: guest)
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

Re: GCC 3.0.3 Prelease problem on --target=m68k-elf

[Peter Barada]

> Ok, how do I file a bug report with GNATS?  I'll have to cobble
> together a test case, but from inspection its obvious that the
> constraint is wrong.

I've generated a testcase that causes the problem.

>Before posting the bug report, you may want to see if your
>bug is the same as:
>http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=5099&database=gcc
>(login: guest, password: guest)

When I access that URL and enter the login and password given, I end up
at the page that says:

Hold on... Redirecting...
In case it does not work automatically, please follow this link.

And when I click the link, end up back at:
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=5099&database=gcc

I could get to it via:
http://gcc.gnu.org/cgi-bin/gnatsweb.pl
without getting asked to log in.  Strange...

And no, these are not the same.  5099 mentions an ICE caused by a
constraint of 'h', but this problem is caused by a constraint(that is
legal for the 68xxx) that isn't legal for the 5200 (or other coldfire
cores/chips). 

I've filed a PR on it.  Bernard Dautrevaux
<Dutrevaux@microprocess.com> responed with a better fix than the one I
suggested. 


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

Re: GCC 3.0.3 Prelease problem on --target=m68k-elf

[Joe Buck]

Peter Barada:
> >> Unfortunately it doesn't produce correct code for -m5200 due to the
> >> "r" constraint in the following pattern in gcc/config/m68k/m68k.md:
> >> 
> >> ;; Jump to variable address from dispatch table of relative addresses.
> >> (define_insn ""
> >>   [(set (pc)
> >> 	(plus:SI (pc)
> >> 		 (sign_extend:SI (match_operand:HI 0 "register_operand" "r"))))
> >>    (use (label_ref (match_operand 1 "" "")))]
> >>   ""

me:
> >Is this a regression with respect to 3.0.2, or 2.95.3?

Peter:
> Its a regression from 2.95.3, the same problem is in 3.0.2.

Then I don't think it should hold up the 3.0.3 release, since 3.0.3
is an improvement over 3.0.2.  But we do want to get it fixed.

> >Either way, it seems the thing to do is to file a bug report with GNATS
> >including a test case for which bad code generation occurs.
> 
> Ok, how do I file a bug report with GNATS?  I'll have to cobble
> together a test case, but from inspection its obvious that the
> constraint is wrong.

Right, but a test case will be needed for the regression test that whoever
fixes the bug will have to create.

The simplest way is to fire up the "gccbug" program, it will walk you
through the process.  (The program is included in the distribution and is
installed when you do a make install).

There's also a web interface: click the GNATS link on http://gcc.gnu.org,
Then click the button for "Create Problem Report".

Re: GCC 3.0.3 Prelease problem on --target=m68k-elf

[Mark Mitchell]

>> Its a regression from 2.95.3, the same problem is in 3.0.2.
>
> Then I don't think it should hold up the 3.0.3 release, since 3.0.3
> is an improvement over 3.0.2.  But we do want to get it fixed.

I agree.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

RE: GCC 3.0.3 Prelease problem on --target=m68k-elf

[Bernard Dautrevaux]

> -----Original Message-----
> From: Peter Barada [mailto:pbarada@mail.wm.sps.mot.com]
> Sent: Friday, December 14, 2001 2:10 AM
> To: gcc@gcc.gnu.org
> Subject: Re: GCC 3.0.3 Prelease problem on --target=m68k-elf
> 
> 
> 
> gcc-3.0.3-20011213 builds with the following config.status:
> #!/bin/sh
> # This file was generated automatically by configure.  Do not edit.
> # This directory was configured as follows:
> /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.0.3-20
> 011213/configure 
> --with-gcc-version-trigger=/home/pbarada/work/cvs-wavemark/cro
> ss-linux-tools/gcc-3.0.3-20011213/gcc/version.c 
> --host=i686-pc-linux-gnu --target=m68k-elf 
> --prefix=/tmp/crap5 --enable-languages=c 
> --with-local-prefix=/tmp/crap5/m68k-elf --without-headers 
> --with-newlib --disable-shared --norecursion 
> # 
> 
> Unfortunately it doesn't produce correct code for -m5200 due to the
> "r" constraint in the following pattern in gcc/config/m68k/m68k.md:
> 
> ;; Jump to variable address from dispatch table of relative addresses.
> (define_insn ""
>   [(set (pc)
> 	(plus:SI (pc)
> 		 (sign_extend:SI (match_operand:HI 0 
> "register_operand" "r"))))
>    (use (label_ref (match_operand 1 "" "")))]
>   ""
> 
> On Coldfire the ext.l instruction can only extend data registers, not
> address registers, so either the constraint needs to be changed to
> "d", or another pettern needs to be created for TARGET_5200 with a "d"
> constraint, and this needs a condition of !TARGET_5200.
> 

I'm not sure this has anything to do with the 5200. On ALL 68k processors
"ext" instructions are only usable on data registers and that's
understandable: loading a word (16bits) in an address register caus
*automatic* sign extension to 32 bits. There is no way to load a 16bits
unsigned constant in an address register.

The assembler generation part of the pattern you list here was, at least on
2.93.3:  

  if (TARGET_5200) 
    return \"ext%.l %0\;jmp 6(%%pc,%0.l)\";
  else
    return \"jmp 6(%%pc,%0.w)\";

It should in fact be changed to:

  if (TARGET_5200 && !ADDRESS_REG_P (operands[0]))
    return \"ext%.l %0\;jmp 6(%%pc,%0.l)\";
  else
    return \"jmp 6(%%pc,%0.w)\";

or even

  if (ADDRESS_REG_P (operands[0]))
    return \"jmp 6(%%pc,%0.l)\";    
  else if (TARGET_5200) 
    return \"ext%.l %0\;jmp 6(%%pc,%0.l)\";
  else
    return \"jmp 6(%%pc,%0.w)\";

I think this was always present in m68k.md, but was masked by the fact that
this is used only in a very limited context where pre 3.0 gcc version always
loaded the table offset in a data register...

HTH

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
--------------------------------------------